Коли мова йде про дані на ланцюгу, багато хто перше, що приходить у голову — це "незмінність". Звучить логічно, але коли ви справді керуєте проектом деякий час, ви натрапите на реальну проблему — іноді потрібно повернутися назад.

Не для того, щоб змінити дані, а щоб зрозуміти, що саме сталося, відслідкувати корінь проблеми, провести аудит ризиків. Це цілком нормальні бізнес-процеси.

Проблема в тому: якщо дані можуть лише рухатися вперед, а система не може розібратися у причинах, її практична цінність фактично знижується. Реальні застосунки вимагають розуміти, як певний стан поступово перетворився у теперішній, а не лише зосереджуватися на кінцевому результаті.

Ідея Walrus досить цікава — вона не йде шляхом радикальних змін. Вона не заперечує цінність незмінності, а інтегрує концепцію "еволюції стану" у механізм валідації. В результаті: ID об'єкта залишається незмінним, кожне оновлення можна відслідкувати, дані не будуть випадково перезаписані, а історичні версії не зникнуть.

З відкритої інформації тестової мережі видно, що ця схема підтримує багаторазове оновлення одного й того ж об'єкта, адреса посилання залишається стабільною, один об'єкт може досягати кількості MB, що достатньо для реальних бізнес-даних.

Якщо дивитися з мого боку, то коли застосунок починає справді зосереджуватися на історії, а не лише на поточному знімку, переваги такої конструкції стають очевидними. Але є один важливий момент — сама мережа має бути стабільною. Якщо учасників мало, багаторівневе відслідковування еволюції може перетворитися на навантаження.

Але в хорошому сенсі — ця ідея справді вирішує одну з актуальних проблем.