By Bitcoin مجلة - منذ سنة - وقت القراءة: 1 دقائق
تسمح سلاسل الدفع لمشغلي عقدة Sidechain بدفع أجور عمال المناجم للتعدين - والمزيد!
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. كان لدى Paul Sztorc ، مبتكر المفهوم ، بعض أهداف التصميم الرئيسية في الاعتبار ، وعلى الرغم من أن هذا ليس شاملاً على الإطلاق ، فإليك بعضًا منها:
Isolate each sidechain so any failure or problem would only affect those using it.Allow sidechains to be spun up without needing a new fork for each one.Enable the transfer of bitcoin in and out of a sidechain with a two-way peg.Allow for free experimentation in design he hopes would obsolete the need for altcoins.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 في غضون قواعد الإجماع drivechain. لاقتراح تنشيط سلسلة جانبية جديدة ، يجب على المُعدِّن وضع بيانات 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 واحد يحتوي على جميع الأموال المحجوزة فيه. يتم التعامل مع عمليات السحب عن طريق تصويت عامل المناجم. ليس لدى mainchain أي فهم لمن يمتلك ماذا على السلسلة الجانبية ، وسوف تعتبر mainchain أي سحب موافق عليه من قبل عمال المناجم ضمن آلية التصويت صالحًا. لهذا السبب ، هناك تأخير طويل في عملية الانسحاب. هناك مرحلتان لعملية الانسحاب من السلسلة الجانبية: اقتراح الانسحاب (الحزمة) ، ثم مرحلة التصويت على الانسحاب. يجب على المعدنين إنشاء مخرجات OP_RETURN في معاملة coinbase الخاصة بهم مع تجزئة معاملة السحب المقترحة لاقتراح سحب. ومع ذلك ، فإن هذا التجزئة ، على غرار sighash ، يشير فقط إلى الالتزام بجزء من المعاملة بدلاً من الشيء بأكمله. لا تلتزم بمدخل 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.
إخراج القبول بسيط للغاية: بيانات رأس الرسالة وتجزئة كتلة السلسلة الجانبية. إذا كان المُعَدِّن يدير عقدة سلسلة القيادة بنفسه ، فيمكنه ببساطة تجاهل معاملات الطلب وإدراج مخرجات القبول الخاصة به دائمًا في قاعدة العملات الخاصة به لتعدين كتل السلسلة الجانبية الخاصة به. يسمح هذان الجانبان معًا لعمال المناجم إما بتشغيل عقدة جانبية بأنفسهم ، أو غيرهم من غير المعدنين للقيام بذلك ودفع لعمال المناجم لتعدين كتلهم. الفكرة هي أنه إذا كان عمال المناجم أنفسهم لا يديرون السلاسل الجانبية ويأكلون تكاليف التحقق الإضافية ، فيمكن لشخص آخر القيام بذلك نيابة عنهم. إذا كانت هناك منافسة بين غير المعدنين الذين يحاولون كسب رسوم على السلسلة الجانبية ، فمن المحتمل أن يستمروا في المزايدة على الرسوم التي يرغبون في دفعها لعمال المناجم في معاملة الطلب الخاصة بهم حتى يمثل غالبية الرسوم التي يكسبونها ، مع عدم - عامل منجم يحتفظ فقط بنسبة صغيرة من الربح ويدفع الباقي لعمال المناجم.
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.
هذا منشور ضيف بواسطة Shinobi. الآراء المعبر عنها هي آراء خاصة بها ولا تعكس بالضرورة آراء BTC Inc أو Bitcoin مجلة.
المصدر الأصلي: Bitcoin مدونة