Changan Chain использует эффективное параллельное планирование для выполнения транзакций.Понимание планирования транзакций Changan Chain, обнаружения конфликтов и процесса создания DAG поможет разработчикам лучше понять рабочий механизм параллельного планирования Changan Chain, а также поможет разработчикам писать высококачественные смарт-контракты с низким уровнем конфликтов для лучше создавайте блокчейн-приложения.
Мы воспользуемся двумя статьями, чтобы объяснить планирование транзакций цепочки Changan, процесс обнаружения конфликтов и процесс построения DAG.
I. Обзор
1. Основные понятия
Планирование выполнения транзакций — это основной процесс выполнения транзакций блокчейна, который оказывает огромное влияние на производительность раунда консенсуса. Суть выполнения транзакции заключается в чтении и записи определенных ключей.В блокчейне блок часто содержит несколько транзакций.Последнее состояние данных после выполнения транзакции называется «мировым состоянием». Существует два способа планирования и выполнения транзакций в блоке. Один — детерминированное планирование, например, простейшее последовательное выполнение; другой — недетерминированное планирование. Таким образом, чтобы улучшить производительность планирования выполнения, часто увеличивайте параллелизм выполнение транзакции. При параллельном выполнении транзакций необходимо обеспечить «правильность» и «порядок» выполнения всех транзакций.
● Корректность: во время выполнения транзакции предварительные достаточные условия, на которых она основана, не могут быть уничтожены (по сути, транзакции с конфликтом чтения и записи не могут выполняться одновременно).
● Упорядоченность: все узлы могут выполнять транзакции в блоке в одном и том же порядке выполнения для получения согласованного мирового состояния (главный узел должен сообщить подчиненным узлам, в каком порядке выполнять транзакции).
2. Построение сцены
Для удобства понимания мы составим простой договор банковского кредита. Когда дочерняя компания обращается за кредитом в банке, она должна быть гарантирована депозитом вышестоящей компании или головного офиса. Если сумма депозита вышестоящей компании составляет не меньше суммы кредита, банк предоставит дочерней компании. Кредиты выдаются и немедленно зачисляются на счета дочерней компании.
Рисунок 1.1 Состояние мира
Если предположить, что k1 — это счет головного офиса, k2 — это дочерний счет первого уровня, а k3 — это дочерний счет второго уровня, текущее состояние мира показано на рисунке выше. В одном блоке находятся четыре транзакции по оформлению кредитов в банках:
Рисунок 1. Четыре конфликтующие транзакции в блоке
● tx0 означает, что дочерняя компания первого уровня k2 обращается за кредитом в банке под гарантию депозита головного офиса k1;
● tx1 означает, что дочерняя компания второго уровня k3 обращается за кредитом в банке с депозитом дочерней компании первого уровня k2 в качестве гарантии;
● tx2 означает, что дочерняя компания второго уровня k3 подает заявку на кредит в банке с депозитом головного офиса k1 в качестве гарантии;
● tx3 означает, что дочерняя компания первого уровня k2 подает заявку на кредит в банке с депозитом головного офиса k1 в качестве гарантии.
Среди них существует конфликт чтения-записи между tx0 и tx1, конфликт записи-записи между tx1 и t2 и конфликт записи-чтения между tx3 и tx1.
2. Обнаружение конфликта транзакций
Если все транзакции в блоке выполняются последовательно, это не повлияет на правильность выполнения всех транзакций. Даже если две транзакции читают и записывают один и тот же ключ, последующая транзакция будет выполнена раньше предыдущей транзакции, выполненной в более позднем «мировом состоянии». , результат выполнения транзакции также верен.
Рисунок 2.1 Последовательное выполнение транзакции
Возьмите приведенные выше tx0 и tx1 в качестве примера: если баланс счета k1 головного офиса составляет 100 юаней (v1), а балансы счетов k2 и k3 дочерних компаний первого и второго уровня составляют 0 юаней соответственно, сумма депозита Компания верхнего уровня используется в качестве гарантии при подаче заявки на кредит в размере 100 юаней. Несмотря на наличие конфликтов чтения и записи, при последовательном выполнении последняя транзакция выполняется на основе последнего мирового состояния предыдущей транзакции, а результаты выполнения двух транзакций являются детерминированными. В частности, на приведенном выше рисунке есть две ситуации:
● В первом случае сначала выполняется tx0, кредит успешен, и баланс дочерней компании первого уровня k2 становится 100 юаней, а tx1, выполненный позже, будет соответствовать условиям банковского кредита, поскольку баланс счета первого уровня дочерняя компания k2 становится 100 юаней, и кредит выдается.
● Во втором случае сначала выполняется tx1, поскольку баланс дочерней компании первого уровня k2 равен 0, поэтому кредит не выдается, но tx0, выполненный позже, будет успешным, поскольку баланс головного офиса k1 все еще составляет 100 юаней.
В случае последовательного выполнения будет выполнен только один из двух вышеуказанных случаев, но независимо от того, какой случай будет выполнен, результат выполнения транзакции определен, и это также правильный результат в соответствии с бизнес-логикой.
Однако для повышения производительности планирования выполнения транзакций при использовании параллельного планирования ситуация будет значительно сложнее: необходимо определить, какие транзакции, исполняемые параллельно, имеют конфликты (гарантировать корректность), а конфликтующие транзакции необходимо выполняются последовательно, а также необходимо указать другим узлам выполнять эти транзакции в этом порядке (для обеспечения порядка).
Далее в этой части рассказывается, как обеспечить правильность, а во второй части — как обеспечить порядок.
1. Конфликты чтения-записи, записи-чтения необходимо выполнить повторно.
При оценке правильности выполнения транзакции конфликты чтения-записи и конфликты записи-чтения по сути представляют собой тип конфликта, то есть содержимое набора чтения, от которого зависит транзакция, модифицируется другими транзакциями в процессе выполнения, что делает транзакция правильная. Если предварительные достаточные условия выполнения нарушены, то корректность результата выполнения транзакции не может быть гарантирована, поэтому транзакцию необходимо выполнить повторно.
Рисунок 2.2. Конфликты чтения и записи транзакций
Как показано на рисунке выше, когда tx0 и tx1 выполняются параллельно, если они выполняются в соответствии с ситуацией на левом рисунке, не будет конфликтов чтения-записи и не будет проблем с корректностью, поэтому последняя транзакция не требует повторного выполнения. Однако, если он выполняется в соответствии с ситуацией, показанной на рисунке справа, между tx1 и tx0 возникает конфликт чтения-записи.K2, на который опирается tx1 в начале выполнения транзакции, изменяется tx0 во время выполнения tx1. В этом случае необходимо обновить tx1 после выполнения. Только повторным выполнением на основе последнего «мирового состояния» после выполнения tx0 можно получить правильный результат.
Рисунок 2.3. Конфликт чтения-записи транзакции (конфликт чтения-записи развился из конфликта записи-чтения)
Как показано на рисунке выше, когда tx1 и tx3 выполняются параллельно, если они выполняются в соответствии с ситуацией, показанной в левой части рисунка 2.3, не будет конфликтов чтения-записи и не будет проблем с корректностью, поэтому последнюю транзакцию не нужно выполнять повторно. Однако в случае справа существует конфликт чтения-записи между tx1 и tx3, и k2, от которого зависит позднее выполненный tx1, модифицируется tx3 во время выполнения tx1, тогда выполняемый позже tx1 необходимо переопределить. -выполнено для получения правильного результата. Здесь подчеркивается, что интуитивный конфликт записи-чтения повлияет на корректность транзакции после выполнения, когда он перерастет в конфликт чтения-записи во время параллельного выполнения.
2. Чтение и чтение без конфликтов, запись и запись напрямую перезаписываются.
Что касается ситуации чтения и чтения, мы не будем объяснять слишком много, потому что в случае отсутствия записи, если один и тот же ключ читается одновременно, все полученные значения являются последовательными и правильными результатами, и нет проблемы правильности параллельного выполнения. исполнение.
Для записи и записи это также относительно просто: запись и запись можно напрямую перезаписать, а значение, записанное в следующей транзакции, можно использовать в качестве конечного результата.
Рисунок 2.4 Перезапись записи
Как показано на рисунке выше, и tx1, и tx2 выполняют операции записи на k3. Если tx1 выполняется первым, а tx2 выполняется, как показано на левой диаграмме рисунка 2.4, логика изменения значения k3 следующая: v3->v3'-> v3'', этот процесс выполнения правильный. Если сначала выполняется tx2, а затем tx1, как показано на рисунке справа, и логика изменения значения k3 следующая: v3->v3''->v3', этот процесс выполнения также является правильным. Независимо от того, какая последовательность выполнения используется, процесс выполнения двух транзакций логичен, и проблем с корректностью нет (поскольку ни одна транзакция не читает k3, и нет конфликта чтения-записи), необходимо только убедиться, что другие узлы также выполняются в том же порядке, что является еще одним требованием порядка.
3. Схема обнаружения конфликтов транзакций в сети Changan
После приведенного выше анализа мы можем знать, что: обнаружение конфликтов транзакций при одновременном выполнении требует только обнаружения конфликтов чтения и записи и повторного выполнения транзакций, которые выполняются позже, до тех пор, пока не исчезнут конфликты чтения и записи во время выполнения всех транзакций.
Опять же, обнаружение конфликтов транзакций здесь может гарантировать только то, что транзакции с конфликтами чтения-записи могут выполняться в определенном порядке, чтобы получить правильные результаты во время процесса выполнения планирования, который удовлетворяет только условию корректности. Как сообщить другим узлам, порядок, в котором этот узел выполняет транзакции, гарантируется условием заказа. Это ответственность за создание DAG во второй статье позже. Пожалуйста, не путайте это.
Рисунок 3.1 Блок-схема обнаружения конфликтов
В цепочке Changan модуль Scheduler отвечает за планирование и выполнение каждого блока.При планировании и выполнении каждого блока Scheduler создаст структуру Snapshot для каждого блока.В этой структуре есть четыре переменные, на которых необходимо сосредоточиться. :
● ExecutedTxs: Очередь выполненных транзакций представляет собой структуру Slice. Каждый раз, когда транзакция выполняется «правильно», она добавляется в очередь, а индекс очереди начинается с 0. Кроме того, при обработке каждой транзакции для создания simContext номер выполнения txSeq текущей транзакции вычисляется с помощью len(ExecutedTxs);
● WriteTable: последний набор наборов записи транзакций, который представляет собой набор карт, ключ — это ключ в наборе записи транзакции, а значение — это значение, соответствующее ключу набора записи и txSeq соответствующей транзакции;
● ReadTable: последний набор наборов чтения транзакций, который также является набором карт, ключ — это ключ в наборе чтения транзакций, а значение — это значение, соответствующее ключу набора чтения и txSeq соответствующей транзакции;
● Блокировка: блокировка чтения и записи в моментальном снимке, которая обеспечивает правильность переменных в моментальном снимке при одновременных операциях.
WriteTable и ReadTable можно понимать как данные горячей точки, которые необходимо изменить и прочитать в среде песочницы, где выполняется блок, вместе с данными в базе данных для формирования последнего «мирового состояния».
Рисунок 3.2. Три структуры данных в Snapshot
конкретный процесс:
1. Во-первых, распределите транзакции в блоке по каналу канала. Распределение транзакций здесь имеет некоторые оптимизации. Его можно сгруппировать по газовому счету или отправителю, а одновременное планирование между различными группами может быть реализовано, насколько это возможно, для уменьшить конфликт чтения и письма.Ситуация здесь подробно не описана;
2. Несколько горутин одновременно извлекают транзакции из канала и выполняют их параллельно.Уровень параллелизма по умолчанию в 4 раза превышает количество ядер ЦП, поэтому 4 транзакции в этом блоке выполняются полностью параллельно.Вот реализация. пул одновременных сопрограмм также может быть адаптивно настроен в соответствии с частотой конфликтов транзакций, которая не будет здесь подробно описываться;
2.1 Прежде чем каждая транзакция фактически вызывает виртуальную машину для выполнения, ей необходимо получить номер выполнения txSeq текущей транзакции через Snapshot, который используется для создания SimContext;
2.2 На данный момент транзакция еще не выполнена, поэтому все txSeq, полученные в четырех транзакциях, равны 0, что рассчитывается с помощью len(ExecutedTxs);
3. 4 сопрограммы параллельно вызывают модуль vm для выполнения 4 транзакций и генерируют набор чтения-записи для каждой транзакции. Фактически, когда VM выполняет контракт, она также сначала читает из WriteTable и ReadTable, и нет нужно прочитать из БД значение;
4. Модуль vm возвращает результат выполнения транзакции, включая набор операций чтения-записи, в модуль планирования;
5. Модуль планирования выполняет обнаружение конфликта транзакций по завершенной транзакции.Если одновременно выполняются следующие два условия, это означает, что транзакция конфликтует:
● Ключ набора чтения в этой транзакции (предполагается, что это k0) находится в WriteTable;
● И txSeq этой транзакции меньше или равен txSeq, соответствующему k0 в WriteTable;
6. Если нет конфликта чтения-записи между транзакцией и ранее выполненной транзакцией, поместите транзакцию в очередь ExecutedTxs и обновите WriteTable и ReadTable, используя набор чтения-записи и txSeq транзакции;
7. Если между транзакцией и транзакцией, которая была выполнена ранее, существует конфликт чтения-записи, транзакция будет перепланирована и распределена, помещена в канал канала, а затем выполнена снова, пока все транзакции не пройдут проверку обнаружения конфликта транзакций во время выполнения. .
Ниже в качестве примеров используются tx0 и tx1, объясняющие, как обнаруживать конфликты чтения и записи.
Рисунок 3.3 Пример схемы обнаружения конфликтов
Как показано на левом рисунке выше, в этом случае нет конфликта чтения-записи. tx0 и tx1 выполняются параллельно и чередуются. Хотя txSeq один и тот же, tx1 выполняется до tx0. После выполнения tx1 WriteTable кэширует последнее значение, соответствующее k3 и txSeq. Когда выполнение tx0 завершено, набор чтения k1 tx0 отсутствует в WriteTable, то есть преддостаточное условие, от которого зависит выполнение транзакции tx0, не нарушено, и выполнение tx0 корректно. время добавьте tx0 в очередь ExecutedTxs и используйте набор для чтения и записи транзакции. Просто обновите WriteTable и ReadTable с помощью txSeq.
Как показано на правом рисунке выше, в этом случае возникает конфликт чтения и записи.tx0 выполняется до tx1.После выполнения tx0 последнее значение, соответствующее k2 и txSeq, будет кэшировано в WriteTable. Когда выполнение tx1 завершено, набор чтения k2 tx1 находится в WriteTable, а txSeq tx1 равен 0, что меньше или равно последней последовательности выполнения 0 k2 в WriteTable. от которого зависит выполнение транзакции tx1 уничтожается, а выполнение tx1 терпит неудачу.В это время необходимо перепланировать и распределить tx1, а затем выполнить его снова.
Рисунок 3.4 Повторное выполнение после конфликта
Когда tx1 выполняется повторно, предполагая, что выполняется только эта транзакция, значение txSeq будет равно 1 для len(ExecutedTxs), а затем, когда виртуальная машина выполнит транзакцию, она будет преимущественно считывать k2 из WriteTable и ReadTable Value Snapshot, результатом, прочитанным на данный момент, является последняя версия v2". После выполнения tx1 обнаруживается, что, хотя k2 находится в WriteTable, его txSeq на 1 больше, чем txSeq 0 в WriteTable, поэтому конфликта нет. Добавьте tx1 в очередь ExecutedTxs. И обновите WriteTable и ReadTable, указав набор для чтения и записи и txSeq транзакции.
4. Вывод
До сих пор мы представили процесс и механизм планирования транзакций и обнаружения конфликтов транзакций в цепочке Changan. На данный момент обеспечивается правильность процесса выполнения транзакций. В следующей статье мы представим, как цепочка Changan реализует упорядоченное выполнение. сделок.