Руководство разработчика TRON — Virtual Machine Хранилище

Image for post
Image for post

Вступление

В Virtual Machine, работающей на протоколе TRON, TVM требует способность взаимодействовать с данными в блокчейне. Следовательно, он должен быть в состоянии помочь смарт-контрактам получить доступ к данным блокчейна.

Существует два метода, с помощью которых смарт-контракты получают доступ к блокчейну:

  1. Данные блокчейна (то есть Данные Аккаунта, Данные Голосования, Выдача Токена и т.д.)
  2. Данные Смарт-Контракта: Хранение

Доступ к Данным в Цепи

Во время работы TVM часто возникают запросы к данным цепи, таким как данные аккаунта и данные выдачи токена. Во время разработки TRON, чтобы предотвратить регулярные запросы в цепь на жестком диске, каждое заключение смарт-контракта будет создавать связанный кэш данных блокчейна. Для каждого смарт-контракта один и тот же ключ можно использовать только два раза для доступа к LevelDB, один раз для первого чтения и еще раз для новых данных (включая удаление ключа).

Хранилище

Хранилище предназначено для сохранения статуса смарт-контракта. Каждый контракт использует свое собственное Хранилище в Solidity. В Solidity, основными командами для доступа к данным Хранилища являются SLOAD и STORE.

Данные в Хранилище — это несколько пар Ключей-Значения, включая ключ-хранилища и значение-хранилища, и пара Ключ-Значения — это слово (32 байта в solidity).

В Solidity разные типы данных имеют соответствующие правила для определения их структуры, как указано в этом документе. Solidity определяет логическую структуру Ключа Хранения. Для разных контрактов может отображаться один и тот же ключ хранения, поэтому хранилище не может быть напрямую сохранено в существующей базе данных (LevelDB) в своей логической структуре. Для более эффективного объединения с цепью, физическое хранилище в цепи должно быть спроектировано соответствующим образом.

Поскольку доступ к хранилищу в смарт-контракте часто является лишь частью ключа хранилища, лучше загружать хранилище с помощью доступа по требованию, чем каждый раз загружать все хранилище в память. Таким образом, ключ хранения в каждом контракте должен быть глобально уникальным, чтобы иметь возможность хранить его в одной и той же базе данных.

Логическая структура ключа хранения определяет последующие 16 байтов для обеспечения уникальности ключа хранения в том же контракте. Таким образом, вы можете использовать хэш адреса контракта и последние 16 байтов ключа хранилища, чтобы сформировать глобально уникальный ключ. Логика композиции выглядит следующим образом:

Written by

@tronfoundation - это проект, посвященный созданию инфраструктуры для децентрализованного Интернета. Основатель и CEO: @jusntinsuntron

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store