Отделение хранения от исполнения в блокчейне RSK
В эти годы я программировал журнал, используя TDD (Test-Driven Programming), чтобы постоянно обучаться дизайну и навыкам разработчика. На мой взгляд, TDD — отличный рабочий процесс для поиска решений для эмерджентного проектирования в простых и сложных областях. Одной из моих любимых областей является блокчейн, и я написал тонны кода на Java, C# и JavaScript, даже смарт-контракты Solidity. Самый яркий пример — мой личный блокчейн-проект на Java (см. также мои опубликованные посты).
О блокчейне я узнал благодаря работе в РСК. Флагманский продукт компании — это блокчейн, похожий на Ethereum, связанный с блокчейном Биткойн. Узел с открытым исходным кодом — производная работа от реализации EthereumJ (сейчас устарела).
Одна вещь, которую я узнал из своих личных экспериментов по внедрению блокчейна, заключается в том, что хранилище смарт-контрактов, подобное Ethereum, МОЖЕТ (и ДОЛЖНО) БЫТЬ отделено от выполнения блока/транзакции. Я описал часть своей реализации в статье Создание блокчейна: выполнение смарт-контрактов.
Обычная реализация в Ethereum для хранения смарт-контрактов включает использование Trie (общее описание см. в разделе Объяснение архитектуры Trie State Ethereum). Внедрение Trie — прекрасная работа, и с помощью TDD я реализовывал ее много раз (включая большую часть кода новой реализации Trie для RSK, которую я написал в 2016 году, завершил и проверил с помощью командной работы, заменив исходную реализацию EthereumJ).
С тех пор я думаю, что выполнение смарт-контракта может быть выполнено БЕЗ знания о существовании дерева. То есть хранение можно легко отделить от исполнения.
Я начал предлагать RSK в 2018 году (см. ветку), чтобы избавиться от любой связи (реализация EthereumJ была очень запутанной в этой области). Но проект пошел по другому пути, который, на мой взгляд, не решил эту проблему: ничего при выполнении транзакции НЕ ДОЛЖНО знать о trie-хранилище. Кроме того, я подумал, что более четкая реализация использования и доступа к ячейкам хранения была бы лучше для проекта.
Я написал еще одно предложение для RSK в 2019 году (см. ветку), чтобы иметь экземпляры типа ExecutionContext.java из моего личного проекта. Только TopExecutionContext.java ЗНАЕТ о существовании дерева (и его можно было бы даже улучшить), в то время как ChildExecutionContext.java управляет только внутренним кешем для учетных записей и значений хранилища.
Мои неофициальные эксперименты также показали улучшение времени выполнения (см. мои комментарии в пулреквесте). Есть НЕФОРМАЛЬНЫЕ, но они выглядят хорошо для изучения. Моя первая мысль: повышение производительности связано с этой развязкой и наличием четкого кеша ключ-значение, разделенного по учетной записи и хранилищу, что в большинстве случаев позволяет избежать вычисления длинных ключей trie. Но я должен попытаться улучшить эти эксперименты, но, как известно: нехватка времени, столько идей, только одна жизнь.
Еще кое-что; это разделение облегчает миграцию, чтобы иметь журнал ключевых значений вместо вложенного стека контекста выполнения, избегая злоупотребления извлечением значений из глубоко вложенного кода смарт-контракта. Я напишу реализацию журнала в своем личном проекте, чтобы показать, что она полностью прозрачна для логики выполнения.
(верхнее изображение было взято из поста в блоге Decoupling)
Анхель «Ява» Лопес
