Жизнь транзакции

Чтобы лучше понять жизненный цикл транзакции в сети 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.
ID цепи	Идентификатор, который отличает развертывания сети Aptos (для предотвращения межсетевых атак).

Жизненный цикл транзакции

В этом разделе мы опишем жизненный цикл транзакции T5, с момента ее отправки клиентом до момента ее фиксации в Aptos Blockchain.

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

Рисунок 1.0 Жизненный цикл транзакции

Стрелки на всех изображениях в этой статье начинаются с компонента, инициирующего взаимодействие/действие, и заканчиваются компонентом, над которым выполняется действие. Стрелки не представляют прочитанные, записанные или возвращенные данные.

Жизненный цикл транзакции состоит из пяти этапов:

• Подтверждение: Подтверждение транзакции

• Совместное использование: Совместное использование транзакции с другими валидирующими нодами

• Предложение: Предложение блока

• Исполнение и консенсус: Исполнение блока и достижение консенсуса

• Фиксация: Подтверждение блока

Ниже мы описали, что происходит на каждом этапе, с ссылками на соответствующие взаимодействия компонентов ноды в сети Aptos.

Подтверждение транзакции

Описание	Взаимодействия компонентов узла Aptos
1.Клиент → REST сервис: клиент отправляет транзакцию T5 в REST сервис полной ноды Aptos. Полная нода использует REST сервис для пересылки транзакции в собственный мемпул, который затем пересылает транзакцию в мемпулы, работающие на других узлах в сети. В конечном итоге транзакция будет перенаправлена в мемпул, работающий на валидирующей полной ноде, который отправит ее валидирующей ноде (в данном случае V1).	1. REST сервис
2. REST сервис → Мемпул: REST сервис полной ноды передает транзакцию T5 в мемпул валидатора V1's .	2. REST сервис, 1. Мемпул
3. Мемпул → Виртуальная Машина (VM): мемпул будет использовать компонент виртуальной машины (VM) для проверки транзакций, таких как проверка подписи, проверка баланса учетной записи и защита от воспроизведения с использованием порядкового номера.	4. Мемпул, 3. Виртуальная Машина

Совместное использование транзакции с другими валидирующими нодами

Описание	Взаимодействия компонентов узла Aptos
4. Мемпул: Мемпул будет хранить T5 в буфере памяти. Мемпул может уже содержать несколько транзакций, отправленных с адреса Алисы.	Мемпул
5. Мемпул → Другие Валидаторы: Используя протокол общего мемпула, V1 будет делиться транзакциями (включая T5) в своем мемпуле с другими валидирующими нодами и помещать транзакции, полученные от них, в свой собственный (V1) мемпул.	2. Мемпул

Предложение блока

Описание	Взаимодействия компонентов узла Aptos
6. Консенсус → Мемпул: — поскольку валидатор V1 является инициатором/лидером этой транзакции, он извлечет блок транзакций из своего мемпула и реплицирует этот блок как предложение другим валидирующим нодам через свой компонент консенсуса.	1. Консенсус, 3. Мемпул
7. Консенсус → Другие валидаторы: компонент консенсуса валидатора V1 отвечает за согласование между всеми валидаторами порядка транзакций в предлагаемом блоке.	2. Консенсус

Исполнение блока и достижение консенсуса

Описание	Взаимодействия компонентов узла Aptos
8. Консенсус → Исполнение: в рамках достижения соглашения блок транзакций (содержащий T5) передается компоненту исполнения.	3. Консенсус, 1. Исполнение
9. Исполнение → Виртуальная машина: компонент выполнения управляет выполнением транзакций в виртуальной машине. Обратите внимание, что это выполнение происходит упреждающе до согласования транзакций в блоке.	2. Исполнение, 3. Виртуальная Машина
10. Консенсус → Выполнение: после выполнения транзакций в блоке исполнительный компонент добавляет транзакции в блоке (включая T5) в аккумулятор Меркла (истории реестра). Это встроенная в память/временная версия накопителя Меркла. Необходимая часть предполагаемого/ориентировочного результата выполнения этих транзакций возвращается компоненту консенсуса для согласования. Стрелка от «консенсуса» к «выполнению» указывает на то, что запрос на выполнение транзакций был сделан компонентом консенсуса.	3. Консенсус, 1. Исполнение
11. Консенсус → Другие валидаторы: V1 (лидер консенсуса) пытается достичь консенсуса по результату выполнения предлагаемого блока с другими валидирующими нодами, участвующими в консенсусе.	3. Консенсус

Подтверждение блока

Описание	Взаимодействия компонентов узла Aptos
12. Консенсус → Выполнение, Выполнение → Хранение: если результат выполнения предложенного блока согласован и подписан сетом валидаторов, имеющих кворум голосов, исполнительный компонент валидатора V1 считывает полный результат выполнения предложенного блока из кэша спекулятивного выполнения и фиксирует все транзакции в предложенном блоке в постоянном хранилище вместе с их результатами.	4. Консенсус, 3. Исполнение, 4. Исполнение, 3. Хранилище

На учетной записи Алисы теперь будет 100 монет Aptos, а ее порядковый номер будет равен 6. Если Боб воспроизведет T5, она будет отклонена, поскольку порядковый номер учетной записи Алисы (6) больше, чем порядковый номер воспроизведенной транзакции (5).

Взаимодействия компонентов узла Aptos

В предыдущем разделе мы описали типичный жизненный цикл транзакции (от отправки до фиксации транзакции). Теперь давайте посмотрим на межкомпонентные взаимодействия узлов Aptos по мере того, как блокчейн обрабатывает транзакции и отвечает на запросы. Эта информация будет наиболее полезна тем, кто:

• хотел бы получить представление о том, как система работает изнутри.

• заинтересован в том, чтобы в конечном итоге внести свой вклад в блокчейн Aptos.

Вы можете узнать больше о различных типах нод Aptos здесь:

• Валидирующие ноды

• Полные ноды

Для объяснения мы предположим, что клиент отправляет транзакцию TN валидатору VX. Для каждого компонента валидатора мы опишем каждое его межкомпонентное взаимодействие в подразделах соответствующего раздела компонента. Обратите внимание, что подразделы, описывающие межкомпонентные взаимодействия, перечислены не строго в том порядке, в котором они выполняются. Большинство взаимодействий относятся к обработке транзакции, а некоторые относятся к клиентам, запрашивающим цепочку блоков (запросы существующей информации в цепочке блоков).

Ниже перечислены основные компоненты ноды Aptos, используемые в жизненном цикле транзакции:

Полная нода

• REST Service

Валидирующая нода

• Мемпул

• Консенсус

• Исполнение

• Виртуальная Машина

• Хранилище

REST сервис

Рисунок 1.1 REST сервис

Любой запрос, сделанный клиентом, сначала направляется в REST сервис полной ноды. Затем отправленная транзакция перенаправляется валидирующей полной ноде, которая затем отправляет ее валидирующей ноде VX.

1. Клиент → REST сервис

Клиент отправляет транзакцию в REST сервис полной ноды Aptos.

2. REST сервис → Мемпул

REST сервис перенаправляет транзакцию валидирующуей полной ноде, который затем отправляет ее в мемпул валидирующей ноды VX. Мемпул примет транзакцию TN только в том случае, если порядковый номер TN больше или равен текущему порядковому номеру учетной записи отправителя (обратите внимание, что транзакция не будет передана на согласование до тех пор, пока порядковый номер не совпадет с порядковым номером учетной записи отправителя).

3. REST сервис → Хранилище

Когда клиент выполняет запрос на чтение данных в Aptos Blockchain (например, чтобы получить баланс учетной записи Алисы), REST сервис напрямую взаимодействует с компонентом хранилища для получения запрошенной информации.

Виртуальная Машина (VM)

Рисунок 1.2 Виртуальная машина

VM Move проверяет и выполняет сценарии транзакций, написанные в байт-коде Move.

1. Виртуальная Машина → Хранилище

Когда мемпул запрашивает VM проверить транзакцию через VM::ValidateTransaction(), VM загружает учетную запись отправителя транзакции из хранилища и выполняет проверки, некоторые из которых описаны в списке ниже. Посмотреть весь список проверок можно здесь.

• Проверка правильности входной подписи подписанной транзакции (для отклонения неверно подписанных транзакций).

• Проверка совпадения ключа аутентификации учетной записи отправителя с хэшем открытого ключа (соответствующего закрытому ключу, используемому для подписи транзакции).

• Проверка того, что порядковый номер транзакции больше или равен текущему порядковому номеру учетной записи отправителя. Выполнение этой проверки предотвращает повторение одной и той же транзакции в учетной записи отправителя.

• Проверка того, что программа в подписанной транзакции не искажена, так как неправильно сформированная программа не может быть выполнена VM.

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

2. Исполнение → Виртуальная Машина

Компонент исполнения использует VM для выполнения транзакции через VM::ExecuteTransaction().

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

3. Мемпул → Виртуальная Машина

Когда мемпул получает транзакцию от других валидаторов через общий мемпул или из REST сервиса, мемпул инициирует на VM команду VM::ValidateTransaction() для проверки транзакции.

Для получения подробной информации о реализации см. Virtual Machine README.

Мемпул

Рисунок 1.3 Мемпул

Мемпул — это общий буфер, в котором хранятся транзакции, «ожидающие» выполнения. При добавлении новой транзакции в мемпул, мемпул делится этой транзакцией с другими валидирующими нодами в системе. Чтобы уменьшить потребление сети в «общем мемпуле», каждый валидатор отвечает за доставку своих транзакций другим валидаторам. Когда валидатор получает транзакцию из мемпула другого валидатора, транзакция добавляется в мемпул валидатора-получателя.

1. REST сервис → Мемпул

После получения транзакции от клиента REST сервис отправляет транзакцию через прокси-сервер на полную ноду валидатора. Затем транзакция отправляется в мемпул валидирующей ноды.

Мемпул валидирующей ноды VX принимает транзакцию TN учетной записи отправителя, только если порядковый номер TN больше или равен текущему порядковому номеру учетной записи отправителя.

2. Мемпул → Другие валидирующие ноды

• Мемпул валидирующей ноды VX делится транзакцией TN с другими валидаторами в той же сети.

• Другие валидаторы делятся транзакциями из своих соответствующих мемпулов с мемпулом валидатора VX.

3. Консенсус → Мемпул

• Когда транзакция перенаправляется валидирующей ноде, и как только валидирующая нода становится лидером, ее компонент консенсуса извлекает блок транзакций из своего мемпула и реплицирует предложенный блок другим валидаторам. Это делается для достижения консенсуса по порядку транзакций и результатам выполнения транзакций в предлагаемом блоке.

• Обратите внимание: то, что транзакция TN была включена в предлагаемый блок консенсуса, не гарантирует, что TN в конечном итоге будет сохранена в распределенной базе данных Aptos Blockchain.

4. Мемпул → VM

Когда мемпул получает транзакцию от других валидаторов, он запускает на VM команду VM::ValidateTransaction() для проверки транзакции.

Для получения подробной информации о реализации см. Mempool README.

Консенсус

Рисунок 1.4 Консенсус

Компонент консенсуса отвечает за упорядочение блоков транзакций и согласование результатов выполнения путем участия в протоколе консенсуса с другими валидаторами в сети.

1. Консенсус → Мемпул

Когда валидатор VX является лидером/инициатором, компонент консенсуса VX извлекает блок транзакций из своего мемпула с помощью: Mempool::GetBlock()и формирует предложенный блок транзакций.

2. Консенсус → Другие Валидаторы

Если VX является инициатором/лидером, его компонент консенсуса реплицирует предложенный блок транзакций другим валидаторам.

3. Консенсус → Исполнение, Консенсус → Другие Валидаторы

• Чтобы выполнить блок транзакций, консенсус взаимодействует с исполнительным компонентом. Консенсус выполняет блок транзакций с помощью Execution:ExecuteBlock() (См. Консенсус → Исполнение).

• После выполнения транзакций в предложенном блоке компонент исполнения отвечает компоненту консенсуса результатом выполнения этих транзакций.

• Компонент консенсуса подписывает результат выполнения и пытается достичь соглашения по этому результату с другими валидаторами.

4. Консенсус → Исполнение

Если достаточное количество валидаторов голосует за один и тот же результат исполнения, компонент консенсуса VX информирует исполнение через Execution::CommitBlock() , что этот блок готов к фиксации.

Для получения подробной информации о реализации см. Consensus README.

Исполнение

Рисунок 1.5 Исполнение

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

1. Консенсус → Исполнение

• Консенсус запрашивает исполнение, чтобы выполнить блок транзакций с помощью: Execution::ExecuteBlock().

• Исполнение поддерживает «электронный блокнот», в котором хранятся копии соответствующих частей аккумулятора Меркла. Эта информация используется для вычисления корневого хэша текущего состояния Aptos Blockchain.

• Корневой хэш текущего состояния объединяется с информацией о транзакциях в предлагаемом блоке для определения нового корневого хэша накопителя. Это делается до сохранения каких-либо данных и для гарантии того, что никакое состояние или транзакция не будут сохранены до тех пор, пока не будет достигнуто согласие кворума валидаторов.

• Исполнение вычисляет спекулятивный корневой хеш, а затем компонент консенсуса VX подписывает этот корневой хэш и пытается достичь соглашения по этому корневому хэшу с другими валидаторами.

2. Исполнение → Виртуальная машина

Когда консенсус запрашивает исполнение выполнить блок транзакций с помощьюExecution::ExecuteBlock(), исполнение использует VM для определения результатов выполнения блока транзакций.

3. Консенсус → Исполнение

Если кворум валидаторов соглашается с результатами выполнения блока, компонент консенсуса каждого валидатора информирует свой исполнительный компонент через Execution::CommitBlock() , что этот блок готов к фиксации. Этот вызов исполнительного компонента будет включать подписи валидаторов, подтверждающие их согласие.

4. Исполнение → Хранилище

Исполнение берет значения из своего «электронного блокнота» и отправляет их в хранилище для сохранения посредством Storage::SaveTransactions(). Затем исполнение удаляет из «электронного блокнота» старые значения, которые больше не нужны (например, параллельные блоки, которые невозможно зафиксировать).

Для получения подробной информации о реализации см. Execution README.

Хранилище

Рисунок 1.6 Хранилище

Компонент хранилища сохраняет согласованные блоки транзакций и результаты их исполнения в Aptos Blockchain. Блок транзакций (который включает транзакцию TN) будет сохранен в хранилище при наличии кворума (2f+1) валидаторов, участвующих в консенсусе. Соглашение должно включать все нижеперечисленное:

• Транзакции для включения в блок

• Порядок транзакций

• Результаты исполнения транзакций в блоке

Ознакомьтесь с информацией по ссылке аккумулятор Меркла, чтобы узнать о том, как транзакция добавляется к структуре данных, представляющей Aptos Blockchain.

1. VM → Хранилище

Когда мемпул инициирует VM::ValidateTransaction() , чтобы проверить транзакцию, VM::ValidateTransaction() загружает учетную запись отправителя из хранилища и выполняет проверку достоверности транзакции только в режиме чтения.

2. Исполнение → Хранилище

Когда компонент консенсуса вызывает Execution::ExecuteBlock(), исполнение считывает текущее состояние из хранилища в сочетании с данными «электронного блокнота» в памяти, чтобы определить результаты исполнения.

3. Исполнение → Хранилище

После достижения консенсуса по блоку транзакций исполнение вызывает хранилище с помощьюStorage::SaveTransactions() , чтобы сохранить блок транзакций и записать их на постоянной основе. Это также сохранит подписи валидирующих нод, которые согласовали данный блок транзакций. Данные в памяти «электронного блокнота» для этого блока передаются для обновления хранилища и сохранения транзакций. При обновлении хранилища порядковый номер каждой учетной записи, измененной этими транзакциями, будет увеличен на единицу.

Note: Порядковый номер учетной записи в Aptos Blockchain увеличивается на единицу для каждой совершенной транзакции, исходящей из этой учетной записи.

4. REST сервис → Хранилище

Для клиентских запросов, которые считывают информацию из блокчейна, REST сервис напрямую взаимодействует с хранилищем для чтения запрошенной информации.

Для получения подробной информации о реализации см. Storage README.