Жизнь транзакции
Last updated
Last updated
Чтобы лучше понять жизненный цикл транзакции в сети Aptos (с операционной точки зрения), мы проследим за транзакцией на ее пути от отправки в полную ноду Aptos до ее подтверждения в Aptos Blockchain. Затем мы сосредоточимся на логических компонентах нод Aptos и посмотрим, как транзакция взаимодействует с этими компонентами.
Для целей данного документа мы предположим, что:
Алиса и Боб являются пользователями Aptos Blockchain, где у каждого из которых есть своя
В аккаунте Алисы есть 110 монет Aptos
Алиса отправляет Бобу 10 монет Aptos
Текущий учетной записи Алисы 5 (что указывает на то, что 5 транзакций уже были отправлены со учетной записи Алисы)
Всего в сети 100 валидирующих нод — от V1 до V100
Клиент Aptos отправляет транзакцию Алисы в REST-сервис на полной ноде Aptos. Полная нода перенаправляет эту транзакцию валидирующей полной ноде, которая в свою очередь направляет ее валидатору V1
Валидатор V1 является инициатором/лидером текущего раунда
Клиент Aptos создает необработанную транзакцию (назовем ее Traw5) для перевода 10 монет Aptos из учетной записи Алисы в учетную запись Боба. Клиент Aptos подписывает транзакцию закрытым ключом Алисы. Подписанная транзакция T5 включает в себя следующее:
Необработанная транзакция
Открытый ключ Алисы
Подпись Алисы
Необработанная транзакция включает следующие поля:
Адрес учетной записи Алисы
Move модуль
Модуль (или программа), указывающий действия, которые необходимо выполнить от имени Алисы. В данном случае он содержит:
скрипт одноранговой транзакции байткода Move
список входных данных для скрипта (в этом примере список будет содержать адрес учетной записи Боба и сумму платежа в монетах Aptos).
Максимальное количество газа, которое Алиса готова заплатить за эту транзакцию. Газ — это способ оплаты вычислений и хранения. Единица газа — это абстрактное измерение вычислений.
Сумма (в монетах Aptos), которую Алиса готова заплатить за единицу газа для выполнения транзакции.
Срок действия транзакции
Порядковый номер (в нашем примере 5) учетной записи указывает количество транзакций, которые были отправлены и зафиксированы в сети с этой учетной записи. В этом случае со счета Алисы было отправлено 5 транзакций, включая Traw5. Примечание: транзакция с порядковым номером 5 может быть совершена в сети только в том случае, если порядковый номер учетной записи равен 5.
Идентификатор, который отличает развертывания сети Aptos (для предотвращения межсетевых атак).
В этом разделе мы опишем жизненный цикл транзакции T5, с момента ее отправки клиентом до момента ее фиксации в Aptos Blockchain.
Для соответствующих шагов мы включили ссылку на соответствующие межкомпонентные взаимодействия валидирующей ноды. После того, как вы ознакомитесь со всеми этапами жизненного цикла транзакции, вы можете обратиться к информации о соответствующих межкомпонентных взаимодействиях для каждого этапа.
Стрелки на всех изображениях в этой статье начинаются с компонента, инициирующего взаимодействие/действие, и заканчиваются компонентом, над которым выполняется действие. Стрелки не представляют прочитанные, записанные или возвращенные данные.
Жизненный цикл транзакции состоит из пяти этапов:
Ниже мы описали, что происходит на каждом этапе, с ссылками на соответствующие взаимодействия компонентов ноды в сети Aptos.
1.Клиент → REST сервис: клиент отправляет транзакцию T5 в REST сервис полной ноды Aptos. Полная нода использует REST сервис для пересылки транзакции в собственный мемпул, который затем пересылает транзакцию в мемпулы, работающие на других узлах в сети. В конечном итоге транзакция будет перенаправлена в мемпул, работающий на валидирующей полной ноде, который отправит ее валидирующей ноде (в данном случае V1).
2. REST сервис → Мемпул: REST сервис полной ноды передает транзакцию T5 в мемпул валидатора V1's .
3. Мемпул → Виртуальная Машина (VM): мемпул будет использовать компонент виртуальной машины (VM) для проверки транзакций, таких как проверка подписи, проверка баланса учетной записи и защита от воспроизведения с использованием порядкового номера.
4. Мемпул: Мемпул будет хранить T5 в буфере памяти. Мемпул может уже содержать несколько транзакций, отправленных с адреса Алисы.
5. Мемпул → Другие Валидаторы: Используя протокол общего мемпула, V1 будет делиться транзакциями (включая T5) в своем мемпуле с другими валидирующими нодами и помещать транзакции, полученные от них, в свой собственный (V1) мемпул.
6. Консенсус → Мемпул: — поскольку валидатор V1 является инициатором/лидером этой транзакции, он извлечет блок транзакций из своего мемпула и реплицирует этот блок как предложение другим валидирующим нодам через свой компонент консенсуса.
7. Консенсус → Другие валидаторы: компонент консенсуса валидатора V1 отвечает за согласование между всеми валидаторами порядка транзакций в предлагаемом блоке.
8. Консенсус → Исполнение: в рамках достижения соглашения блок транзакций (содержащий T5) передается компоненту исполнения.
9. Исполнение → Виртуальная машина: компонент выполнения управляет выполнением транзакций в виртуальной машине. Обратите внимание, что это выполнение происходит упреждающе до согласования транзакций в блоке.
11. Консенсус → Другие валидаторы: V1 (лидер консенсуса) пытается достичь консенсуса по результату выполнения предлагаемого блока с другими валидирующими нодами, участвующими в консенсусе.
12. Консенсус → Выполнение, Выполнение → Хранение: если результат выполнения предложенного блока согласован и подписан сетом валидаторов, имеющих кворум голосов, исполнительный компонент валидатора V1 считывает полный результат выполнения предложенного блока из кэша спекулятивного выполнения и фиксирует все транзакции в предложенном блоке в постоянном хранилище вместе с их результатами.
На учетной записи Алисы теперь будет 100 монет Aptos, а ее порядковый номер будет равен 6. Если Боб воспроизведет T5, она будет отклонена, поскольку порядковый номер учетной записи Алисы (6) больше, чем порядковый номер воспроизведенной транзакции (5).
хотел бы получить представление о том, как система работает изнутри.
заинтересован в том, чтобы в конечном итоге внести свой вклад в блокчейн Aptos.
Вы можете узнать больше о различных типах нод Aptos здесь:
Для объяснения мы предположим, что клиент отправляет транзакцию TN валидатору VX. Для каждого компонента валидатора мы опишем каждое его межкомпонентное взаимодействие в подразделах соответствующего раздела компонента. Обратите внимание, что подразделы, описывающие межкомпонентные взаимодействия, перечислены не строго в том порядке, в котором они выполняются. Большинство взаимодействий относятся к обработке транзакции, а некоторые относятся к клиентам, запрашивающим цепочку блоков (запросы существующей информации в цепочке блоков).
Ниже перечислены основные компоненты ноды Aptos, используемые в жизненном цикле транзакции:
Полная нода
Валидирующая нода
Любой запрос, сделанный клиентом, сначала направляется в REST сервис полной ноды. Затем отправленная транзакция перенаправляется валидирующей полной ноде, которая затем отправляет ее валидирующей ноде VX.
Клиент отправляет транзакцию в REST сервис полной ноды Aptos.
REST сервис перенаправляет транзакцию валидирующуей полной ноде, который затем отправляет ее в мемпул валидирующей ноды VX. Мемпул примет транзакцию TN только в том случае, если порядковый номер TN больше или равен текущему порядковому номеру учетной записи отправителя (обратите внимание, что транзакция не будет передана на согласование до тех пор, пока порядковый номер не совпадет с порядковым номером учетной записи отправителя).
Когда клиент выполняет запрос на чтение данных в Aptos Blockchain (например, чтобы получить баланс учетной записи Алисы), REST сервис напрямую взаимодействует с компонентом хранилища для получения запрошенной информации.
VM Move проверяет и выполняет сценарии транзакций, написанные в байт-коде Move.
Проверка правильности входной подписи подписанной транзакции (для отклонения неверно подписанных транзакций).
Проверка совпадения ключа аутентификации учетной записи отправителя с хэшем открытого ключа (соответствующего закрытому ключу, используемому для подписи транзакции).
Проверка того, что порядковый номер транзакции больше или равен текущему порядковому номеру учетной записи отправителя. Выполнение этой проверки предотвращает повторение одной и той же транзакции в учетной записи отправителя.
Проверка того, что программа в подписанной транзакции не искажена, так как неправильно сформированная программа не может быть выполнена VM.
Проверка того, что баланс учетной записи отправителя содержит по крайней мере максимальное количество газа, умноженное на цену газа, указанную в транзакции, что гарантирует, что транзакция может оплатить используемые ресурсы.
Компонент исполнения использует VM для выполнения транзакции через VM::ExecuteTransaction().
Важно понимать, что выполнение транзакции отличается от обновления состояния реестра и сохранения результатов в хранилище. Транзакция TN сначала выполняется как часть попытки достичь соглашения по блокам во время консенсуса. Если соглашение с другими валидаторами о порядке транзакций и результатах их выполнения достигается, результаты сохраняются в хранилище, а состояние реестра обновляется.
Когда мемпул получает транзакцию от других валидаторов через общий мемпул или из REST сервиса, мемпул инициирует на VM команду VM::ValidateTransaction() для проверки транзакции.
Мемпул — это общий буфер, в котором хранятся транзакции, «ожидающие» выполнения. При добавлении новой транзакции в мемпул, мемпул делится этой транзакцией с другими валидирующими нодами в системе. Чтобы уменьшить потребление сети в «общем мемпуле», каждый валидатор отвечает за доставку своих транзакций другим валидаторам. Когда валидатор получает транзакцию из мемпула другого валидатора, транзакция добавляется в мемпул валидатора-получателя.
После получения транзакции от клиента REST сервис отправляет транзакцию через прокси-сервер на полную ноду валидатора. Затем транзакция отправляется в мемпул валидирующей ноды.
Мемпул валидирующей ноды VX принимает транзакцию TN учетной записи отправителя, только если порядковый номер TN больше или равен текущему порядковому номеру учетной записи отправителя.
Мемпул валидирующей ноды VX делится транзакцией TN с другими валидаторами в той же сети.
Другие валидаторы делятся транзакциями из своих соответствующих мемпулов с мемпулом валидатора VX.
Когда транзакция перенаправляется валидирующей ноде, и как только валидирующая нода становится лидером, ее компонент консенсуса извлекает блок транзакций из своего мемпула и реплицирует предложенный блок другим валидаторам. Это делается для достижения консенсуса по порядку транзакций и результатам выполнения транзакций в предлагаемом блоке.
Обратите внимание: то, что транзакция TN была включена в предлагаемый блок консенсуса, не гарантирует, что TN в конечном итоге будет сохранена в распределенной базе данных Aptos Blockchain.
Когда мемпул получает транзакцию от других валидаторов, он запускает на VM команду VM::ValidateTransaction() для проверки транзакции.
Компонент консенсуса отвечает за упорядочение блоков транзакций и согласование результатов выполнения путем участия в протоколе консенсуса с другими валидаторами в сети.
Когда валидатор VX является лидером/инициатором, компонент консенсуса VX извлекает блок транзакций из своего мемпула с помощью: Mempool::GetBlock()и формирует предложенный блок транзакций.
Если VX является инициатором/лидером, его компонент консенсуса реплицирует предложенный блок транзакций другим валидаторам.
После выполнения транзакций в предложенном блоке компонент исполнения отвечает компоненту консенсуса результатом выполнения этих транзакций.
Компонент консенсуса подписывает результат выполнения и пытается достичь соглашения по этому результату с другими валидаторами.
Если достаточное количество валидаторов голосует за один и тот же результат исполнения, компонент консенсуса VX информирует исполнение через Execution::CommitBlock() , что этот блок готов к фиксации.
Компонент исполнения координирует выполнение блока транзакций и поддерживает переходное состояние, за которое можно проголосовать на основе консенсуса. Если эти транзакции успешны, они фиксируются в хранилище.
Консенсус запрашивает исполнение, чтобы выполнить блок транзакций с помощью: Execution::ExecuteBlock().
Корневой хэш текущего состояния объединяется с информацией о транзакциях в предлагаемом блоке для определения нового корневого хэша накопителя. Это делается до сохранения каких-либо данных и для гарантии того, что никакое состояние или транзакция не будут сохранены до тех пор, пока не будет достигнуто согласие кворума валидаторов.
Исполнение вычисляет спекулятивный корневой хеш, а затем компонент консенсуса VX подписывает этот корневой хэш и пытается достичь соглашения по этому корневому хэшу с другими валидаторами.
Когда консенсус запрашивает исполнение выполнить блок транзакций с помощьюExecution::ExecuteBlock(), исполнение использует VM для определения результатов выполнения блока транзакций.
Если кворум валидаторов соглашается с результатами выполнения блока, компонент консенсуса каждого валидатора информирует свой исполнительный компонент через Execution::CommitBlock() , что этот блок готов к фиксации. Этот вызов исполнительного компонента будет включать подписи валидаторов, подтверждающие их согласие.
Исполнение берет значения из своего «электронного блокнота» и отправляет их в хранилище для сохранения посредством Storage::SaveTransactions(). Затем исполнение удаляет из «электронного блокнота» старые значения, которые больше не нужны (например, параллельные блоки, которые невозможно зафиксировать).
Компонент хранилища сохраняет согласованные блоки транзакций и результаты их исполнения в Aptos Blockchain. Блок транзакций (который включает транзакцию TN) будет сохранен в хранилище при наличии кворума (2f+1) валидаторов, участвующих в консенсусе. Соглашение должно включать все нижеперечисленное:
Транзакции для включения в блок
Порядок транзакций
Результаты исполнения транзакций в блоке
Когда мемпул инициирует VM::ValidateTransaction() , чтобы проверить транзакцию, VM::ValidateTransaction() загружает учетную запись отправителя из хранилища и выполняет проверку достоверности транзакции только в режиме чтения.
Когда компонент консенсуса вызывает Execution::ExecuteBlock(), исполнение считывает текущее состояние из хранилища в сочетании с данными «электронного блокнота» в памяти, чтобы определить результаты исполнения.
После достижения консенсуса по блоку транзакций исполнение вызывает хранилище с помощьюStorage::SaveTransactions() , чтобы сохранить блок транзакций и записать их на постоянной основе. Это также сохранит подписи валидирующих нод, которые согласовали данный блок транзакций. Данные в памяти «электронного блокнота» для этого блока передаются для обновления хранилища и сохранения транзакций. При обновлении хранилища порядковый номер каждой учетной записи, измененной этими транзакциями, будет увеличен на единицу.
Note: Порядковый номер учетной записи в Aptos Blockchain увеличивается на единицу для каждой совершенной транзакции, исходящей из этой учетной записи.
Для клиентских запросов, которые считывают информацию из блокчейна, REST сервис напрямую взаимодействует с хранилищем для чтения запрошенной информации.
Подтверждение:
Совместное использование:
Предложение:
Исполнение и консенсус:
Фиксация:
,
,
,
,
,
10. Консенсус → Выполнение: после выполнения транзакций в блоке исполнительный компонент добавляет транзакции в блоке (включая T5) в (истории реестра). Это встроенная в память/временная версия накопителя Меркла. Необходимая часть предполагаемого/ориентировочного результата выполнения этих транзакций возвращается компоненту консенсуса для согласования. Стрелка от «консенсуса» к «выполнению» указывает на то, что запрос на выполнение транзакций был сделан компонентом консенсуса.
,
, , ,
В мы описали типичный жизненный цикл транзакции (от отправки до фиксации транзакции). Теперь давайте посмотрим на межкомпонентные взаимодействия узлов Aptos по мере того, как блокчейн обрабатывает транзакции и отвечает на запросы. Эта информация будет наиболее полезна тем, кто:
Когда мемпул запрашивает VM проверить транзакцию через VM::ValidateTransaction(), VM загружает учетную запись отправителя транзакции из хранилища и выполняет проверки, некоторые из которых описаны в списке ниже. Посмотреть весь список проверок можно .
Для получения подробной информации о реализации см. .
Для получения подробной информации о реализации см. .
Чтобы выполнить блок транзакций, консенсус взаимодействует с исполнительным компонентом. Консенсус выполняет блок транзакций с помощью Execution:ExecuteBlock() (См. ).
Для получения подробной информации о реализации см. .
Исполнение поддерживает «электронный блокнот», в котором хранятся копии соответствующих частей . Эта информация используется для вычисления корневого хэша текущего состояния Aptos Blockchain.
Для получения подробной информации о реализации см. .
Ознакомьтесь с информацией по ссылке , чтобы узнать о том, как транзакция добавляется к структуре данных, представляющей Aptos Blockchain.
Для получения подробной информации о реализации см. .
