Драйвчейны позволяют операторам узлов сайдчейна платить майнерам за майнинг — и многое другое!

By Bitcoin Журнал - 1 год назад - Время чтения: 7 минуты
Сб, 23 июля 2022 г., 2:00

Драйвчейны позволяют операторам узлов сайдчейна платить майнерам за майнинг — и многое другое!

Drivechains, like softchains, are another sidechain implementation with two-way peg functionality.

Это редакционная статья Шиноби, преподавателя-самоучки из Bitcoin космический и технический Bitcoin ведущий подкаста.

This time I'm going to be breaking down and discussing how drivechains work; they were initially proposed in 2015. Out of all the proposals discussed so far, drivechains are the oldest and the most fleshed out in terms of specific implementation details and design, documented in BIPs 300 и 301. Пол Шторц, создатель концепции, имел в виду несколько основных целей дизайна, и хотя это совсем не исчерпывающе, вот некоторые из них:

There are two primary aspects of the entire design, which is why there are two separate BIPs. The first is the peg mechanism (BIP300), which is what enables the two-way peg to function. Sztorc designed something called a hash rate escrow, which, in the most basic terms, is allowing miners as an amorphous group to collectively custody the coins in all the sidechains. The second is a "blind" merged mining scheme, where the goal is to allow bitcoin miners to be the block producers at a consensus level without being required to validate the sidechain to do so. Both of these pieces together present a two-way peg mechanism and a way for bitcoin miners to take part in mining the sidechains while attempting to mitigate the centralization risk that it presents.

BIP300 определяет логику предложения новой боковой цепи, активации новой боковой цепи, предложения объединенного набора выводов средств, утверждения такого набора выводов средств, логики проверки фактических транзакций вывода средств и проверки депозитных транзакций.

Activating a new sidechain under the drivechain proposal is very similar to the process of a soft fork activated through miner signaling. The major difference is, of course, it's not actually a soft fork — a single fork to activate the drivechain consensus rules allows miners to, at any time, signal to activate a new sidechain в правила консенсуса приводной цепи. Чтобы предложить активацию новой боковой цепи, майнер должен поместить данные OP_RETURN в выходные данные своей базы монет, которые включают в себя уникальный идентификатор этой боковой цепи, открытый ключ для использования в депозитных операциях, данные о версии, удобочитаемые описания и хэши программного клиента. и историю этого на GitHub (здесь нет никакого консенсуса, просто данные, на которые люди могут ссылаться).

When a miner proposes activating a new sidechain and including all the necessary data in their coinbase, it becomes a sort of "miner signaling" period regarding whether or not to create this new sidechain from the point of view of mainchain consensus. A miner can use a special format to include a proposal in their coinbase outputs, and other miners can create another output following a second format to signal for activation. A new sidechain proposal requires 90% of blocks in a difficulty period to signal for activation in order for a new sidechain creation to be confirmed. This creates the peg mechanism to enable the sidechain, but the interaction between sidechain and mainchain is more nuanced than that.

На этом этапе любой может привязать монеты к сайдчейну. Чтобы привязаться к сайдчейну, пользователь просто создает транзакцию с двумя входами со своим собственным входом и UTXO, соответствующим балансу сайдчейна, с одним выходом, присваивающим все сайдчейну. Это гарантирует, что в сайдчейне всегда будет только один UTXO, содержащий все заблокированные в нем средства. Вывод средств осуществляется путем голосования майнеров. Основная цепь не имеет представления о том, кто чем владеет в боковой цепи, и основная цепь будет считать действительным любой вывод средств, одобренный майнерами в рамках механизма голосования. Из-за этого происходит длительная задержка процесса вывода средств. Процесс выхода из сайдчейна состоит из двух этапов: предложение о выходе (пакет), а затем этап голосования за выход. Майнеры должны создать вывод OP_RETURN в своей транзакции Coinbase с хешем предлагаемой транзакции вывода, чтобы предложить вывод. Однако этот хеш, как и сигэш, отмечает только фиксацию части транзакции, а не всей транзакции. Он не фиксирует входной UTXO, который представляет средства, заблокированные в цепочке передачи данных, или выходные данные, которые возвращают все, что не было выведено, в специальный UTXO боковой цепи. Это связано с тем, что любые депозиты в приводную цепь создадут новый UTXO и, таким образом, сделают недействительным обязательство по транзакции вывода средств, когда люди придут ее подтвердить.

From here, the miner voting period on the withdrawal proposal begins. After a bundle has been proposed, miners are able to vote on whether to approve them or not. Each block that is mined allows that miner to increment an approval counter, up or down by one, or two to abstain from doing anything. There are some specific limitations in addition to this, because it is possible to have more than one bundle for a single sidechain — if a miner chooses to vote "yes" (raise the counter by one) for a withdrawal bundle for a sidechain they должен vote "no" (lower the counter by one) for every other bundle associated with that specific sidechain.

This is to guarantee that there are no "double withdrawals," where someone has an output in multiple bundles that would pay them out more bitcoin on the mainchain than they are owed.

On the other side, miners are also allowed to vote no for every single proposed bundle. This is supposed to function as a sort of alarm for everyone that a miner validating these withdrawals (making sure they are legitimately owned coins on the sidechain being withdrawn) has noticed something invalid happening. Remember, a key point of this design is that miners do not have to validate anything on the sidechain, so unless they choose to anyway, many miners may be upvoting bundles they are not verifying. This alarm function is designed for them to be alerted that they should verify the bundles to ensure a fraudulent withdrawal isn't happening.

Once a bundle has reached the required threshold (13,150 blocks, or roughly 90 days), the transaction actually processing the withdrawal becomes valid and can be confirmed. But what do people do if miners approve a fraudulent withdrawal that steals money from the sidechain? Sztorc's proposal is to engage in a user-ctivated soft fork (UASF) to invalidate the invalid peg-out transaction. This presents a huge risk in terms of consensus to the mainchain. The UASF in 2017 was a high-risk move that only barely succeeded and Bitcoin was much smaller than it is today. The larger Bitcoin grows, the more difficult such actions will be to coordinate.

Если вы помните из статья о космических цепях, that design was based around blind merged mining (BMM). Ruben Somsen’s BMM design is actually the second variant of that, the first being Sztorc's design as laid out in BIP301. The BMM spec in drivechains is composed of two messages: a request message and an accept message. Both are coordinated respectively through a special transaction type on the mainchain and special output in a miner's coinbase transaction.

The request transaction is constructed by whoever is creating sidechain blocks. The whole point of BMM is that this person can be someone who is not mining, so the request transaction is there to allow them to pay miners to confirm their proposed sidechain block. The sidechain block proposal constructs a transaction that includes the hash of the sidechain block, the ID assigned to the sidechain when it was created and the last four bytes of the previous mainchain block header. There are three additional consensus rules applied to these types of transactions. First, a request transaction is invalid unless there is also a matching accept output in the coinbase transaction of that block. This is to guarantee miners cannot collect a fee from the request without also accepting and mining the sidechain block. Second, for each sidechain only one request transaction is allowed to be included in a mainchain block. This is to ensure only one block from any sidechain can actually be mined per mainchain block. Lastly, the last four bytes of the previous mainchain block must match. This ensures that a request is only valid to be mined in the next block, and such transactions cannot be mined later and steal money from a sidechain block proposer after someone else's block has been mined.

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

That's the mechanics behind how drivechains function. Next up, federated sidechains, and then, after that, a breakdown of all the negatives and downsides each design can have.

Это гостевой пост Шиноби. Выраженные мнения являются полностью их собственными и не обязательно отражают мнение BTC Inc или Bitcoin Журнал.

Исходный источник: Bitcoin Журнал