กระเป๋าเก็บเงินบนโซ่บล็อกทำให้เกิดการสร้างแมปประมาณ 1:1 ของธุรกรรมกับธุรกรรม: สำหรับทุกธุรกรรมทางเศรษฐกิจที่ผู้ใช้ทำ จำเป็นต้องมีการทำธุรกรรมบล็อกเชนประมาณหนึ่งครั้ง การรวมกลุ่ม การเข้าร่วมเหรียญ การจ่ายทางลัดเป็นต้น จะทำให้ประโยคนี้เปลี่ยนแปลงบ้าง แต่ประมาณถูกต้อง

Lightning ประสบความสําเร็จในการทําแผนที่ธุรกรรมแบบหลายต่อหนึ่งกับธุรกรรม: ความมหัศจรรย์ของ Lightning คือธุรกรรมทางเศรษฐกิจจํานวนไม่ จํากัด อย่างมีประสิทธิภาพสามารถเกิดขึ้นได้ในช่องทาง Lighting เดียวซึ่งเชื่อมโยงกับเอาต์พุตธุรกรรมที่ไม่ได้ใช้ (UTXO) เดียว โดยพื้นฐานแล้วเราได้ใช้มิติ "เวลา" - ธุรกรรม - และบรรลุการปรับขนาดที่สําคัญโดยการยุบมิตินั้น

แต่การสร้าง UTXO แม้แต่ตัวเดียวต่อผู้ใช้นั้นไม่ดีพอ ดังนั้นจึงมีข้อเสนอมากมายเพื่อให้บรรลุการปรับขนาดที่มากขึ้นโดยอนุญาตให้ผู้ใช้หลายคนแบ่งปัน UTXO เดียวในลักษณะที่อธิปไตยตนเอง อีกครั้งการยุบมิติ "ช่องว่าง" อื่นของการปรับขนาด - ผู้ใช้ - เป็น UTXO เดียว

เป้าหมายของเราที่นี่คือทำภาพรวมของการเสนอเสนอทั้งหมดเหล่านี้ หาแนวทางทางเทคนิคที่พวกเขาแชร์ หาโค้ดข้อมูลแบบใหม่และอัพเกรดซอฟต์ฟอร์คอื่น ๆ ที่พวกเขาต้องการให้ทำงาน และสร้างตารางเปรียบเทียบว่าพวกชิ้นส่วนทั้งหมดมีความเข้ากันได้อย่างไร ในระหว่างทางเรายังจะกำหนดว่าโปรโตคอล L2 คืออะไรแท้จริง ขนาดของการขยายฺ Lightning ที่มีความสามารถอยู่แล้ว และเข้าใจว่าเราต้องปรับปรุง mempool เพื่อทำให้สามารถทำทุกอย่างนี้ได้

ขอบคุณไปที่Fulgur Venturesสำหรับการสนับสนุนงานวิจัยนี้ พวกเขาไม่มีการควบคุมในเนื้อหาของโพสต์นี้และไม่ได้ตรวจสอบก่อนการเผยแพร่

ขอบคุณด้วยDaniela Brozzoni, Sarah Cox, และอื่น ๆ สำหรับการทบทวนก่อนการเผยแพร่

คำจำกัดความ

Layer 2 คืออะไร?

บ่อยครั้งที่คําว่า "เลเยอร์ 2" ถูกกําหนดอย่างกว้าง ๆ จนถึงจุดที่แม้แต่เอนทิตีที่เหมือนธนาคาร (เช่นของเหลว) ก็สามารถกําหนดเป็นเลเยอร์ 2 ได้ สําหรับวัตถุประสงค์ของบทความนี้เราจะใช้คําจํากัดความที่เข้มงวด: เลเยอร์ 2 (L2) เป็นระบบสกุลเงิน Bitcoin โดยมีวัตถุประสงค์เพื่อให้ BTC สามารถทําธุรกรรมได้บ่อยกว่าจํานวนธุรกรรมแบบ on-chain กับบุคคลอื่น เช่นนั้นอย่างใดอย่างหนึ่ง:

1. ไม่มีใครสามารถขโมยเงินได้เป็นกำไรในระบบ โดยพิจารณาค่าโทษและค่าใช้จ่ายในระบบ ค่าใช้จ่ายและโทษที่เกิดขึ้นนอกระบบ เช่น การสูญเสียชื่อเสียง ผลกระทบทางกฎหมาย เป็นต้น ไม่ได้รับการพิจารณาในคำจำกัดความของเรา
2. (ต้องการ) เจ้าของทรัพย์สินแท้จริงสามารถถอนเงินของตนได้โดยเดียว ลบค่าธุรกรรม โดยไม่ต้องร่วมมือกับบุคคลที่สามใด ๆ

ตัวเลือกแรกจำเป็นเพราะเราต้องการให้ระบบ L2 ของเราสามารถแสดงผลจำนวนและธุรกรรมที่มีมูลค่าเล็กมาก ที่ไม่สามารถแสดงผลบนเชื่อมโยงได้ เช่นในระบบ Lightning HTLCs สามารถมีมูลค่าที่เล็กเกินไปที่จะแสดงบนเชื่อมโยงได้ ในกรณีนั้นมูลค่า HTLC จะถูกเพิ่มเข้าไปในค่าธรรมเนียมของธุรกรรมการติดตาม ในขณะที่โหนด Lightning สามารถ "ขโมย" HTLC ขนาดเล็กๆ ได้โดยปิดช่องทางในช่วงที่เหมาะสม แต่การทำเช่นนั้นจะมีค่าใช้จ่ายสูงกว่า¹มากกว่า HTLC มีค่า ทำให้การโจรกรรมไม่ได้รับกำไร

อย่างไรก็ตาม การถอนคืนเองเป็นเป้าหมายการออกแบบหลักของเราเสมอ²

ด้วยนิยามนี้ สิ่งที่เรียกว่า Lightning เป็นระบบ L2 แต่ระบบเช่น Liquid, Cashu, และ Fedimint ไม่ใช่ L2 เพราะมีฝ่ายหรือฝ่ายอื่นควบคุมเงินของคุณ ระบบตรวจสอบด้านลูกค้าเช่น RGB ก็ไม่ใช่ L2 ตามนิยามนี้ เพราะไม่สามารถทำธุรกรรม BTC ได้โดยไม่ต้องเชื่อถือ ในท้ายที่สุด@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains ล้มเหลวในการตัดเนื่องจากหน่วยงาน Statechain สามารถขโมยเงินได้หากไม่ปฏิบัติตามโปรโตคอล

Covenants คืออะไร?

...และทำไมระบบ L2 ที่มีความยืดหยุ่นมากขึ้นต้องใช้มัน?

ในการเขียนสคริปต์ Bitcoin พันธสัญญาเป็นกลไกที่วิธีการใช้ txout ถูก จํากัด ไว้ล่วงหน้าเช่นรูปแบบของธุรกรรมที่ใช้ในการใช้จ่ายที่ txout ถูกกําหนดไว้ล่วงหน้าหรือถูก จํากัด ในลักษณะที่ไม่ได้ จํากัด เฉพาะลายเซ็นอย่างหมดจด ระบบ L2 ที่แบ่งปัน UTXOs ระหว่างหลายฝ่ายจําเป็นต้องมีพันธสัญญาเนื่องจากพวกเขาต้องการวิธีการ จํากัด วิธีการใช้ UTXO เพื่อใช้กฎและแรงจูงใจของโปรโตคอล L2

สัญญาที่วนซ้ำ

สัญญาเชื่อมั่นเชิงตัวต่อเนื่อง (Recursive covenant) เป็นสัญญาที่มีลักษณะเฉพาะคือกฎที่จำกัดวิธีการใช้เหรียญ UTXO สามารถนำไปใช้ต่อเนื่องกับ UTXO ลูกของธุรกรรมการใช้เหรียญนั้นๆได้โดยไม่จำกัด สัญญาเชื่อมั่นเชิงตัวต่อเนื่องที่มีลักษณะเช่นนี้เรียกว่า Recursive covenant ถูกพิจารณาว่าไม่ค่อยพอใจโดยบางคนมานานเพราะว่าพวกเขาสามารถเปลี่ยนแปลงเหรียญได้โดยไม่มีกำหนดเวลา หรืออย่างน้อยก็ไม่มีกำหนดเวลาโดยไม่ได้รับอนุญาตจากบุคคลที่สาม เช่นรัฐบาล

เป้าหมาย

ไฟฟ้าสายเลี้ยงเป็นระบบชั้นที่ 2 ที่ดีที่สุดในปัจจุบัน อย่างไรก็ตาม มันยังมีข้อจำกัด คือ:

1. การขยายขอบเขต - Lightning ในปัจจุบันต้องการ UTXO อย่างน้อยหนึ่งรายการต่อผู้ใช้สิ้นสุด³
2. ความเหลือเชื่อม - Lightning ต้องการให้เงินติดตัวในช่องทาง
3. ความสามารถในการติดต่อกัน - Lightning ต้องการผู้รับการชำระเงินอยู่ในโหมดออนไลน์เพื่อรับการชำระเงินได้โดยไม่ต้องไว้วางใจ

ในการประเมินระบบชั้นที่ 2 เป้าหมายของเราคือการปรับปรุงข้อจำกัดสำคัญเหล่านี้โดยที่ไม่เพิ่มข้อจำกัดใหม่ถ้าเป็นไปได้

ขีด จำกัด ของการขยายมิติของ Lightning

ในทางปฏิบัติหมายถึงอะไรกันแน่? เนื่องจากช่องสายแสงสามารถทำงานได้ไม่จำกัดเวลา วิธีหนึ่งในการมองเห็นสิ่งนี้คือถามว่าปีละสามารถสร้างช่องสายใหม่ได้กี่ช่อง⁴การสร้างเอาท์พุต taproot มีค่าใช้จ่ายขนาดเล็กเพียง 43vB; หากการสร้างช่องถูกการแบ่งเบา โดยมีการสร้างช่องมากมายในธุรกรรมเดียว ค่าใช้จ่ายเกี่ยวกับธุรกรรมอื่น ๆ สามารถทำให้เล็กน้อยและสามารถเปิดช่องจำนวนมากได้ต่อปีเพื่อรับผู้ใช้ใหม่เข้ามา ตัวอย่างเช่น สมมติว่า 90% ของความจุบล็อกไปสู่การเปิดช่อง Lightning taproot ใหม่:

มีการประมาณว่าประมาณครึ่งหนึ่งของประชากรโลกเป็นเจ้าของสมาร์ทโฟน, 4.3 พันล้านคน ดังนั้นเราจึงสามารถเข้าร่วมกับส่วนที่สำคัญของประชากรทั้งหมดที่สามารถใช้ช่องฟ้าผ่าไฟได้ต่อปี

อย่างไรก็ตาม, ช่องสื่อสารไม่มีอายุยาวนานเสมอไป บางครั้งผู้ใช้จะต้องการเปลี่ยนกระเป๋าเงิน, เพิ่มหรือลดความจุของช่องสื่อสาร วิธีที่มีประสิทธิภาพที่สุดในการเปลี่ยนแปลงความจุของช่องสื่อสารคือทางต่อเชื่อม, โดยที่ได้นำมาใช้งานอย่างมีชื่อเสียงใน กระเป๋า Phoenix.

เหมือนกับการเปิดช่อง การต่อเชื่อมก็สามารถทำได้ในรูปแบบที่แบ่งเบาได้เพื่อเพิ่มประสิทธิภาพ ด้วยการทำงานต่อเนื่องหลายครั้งการต่อเชื่อมที่ใช้ร่วมกันหลายครั้งจะแบ่งปันธุรกรรมเดียวกันเพื่อลดจำนวนของข้อมูลนำเข้าและข้อมูลส่งออกที่จำเป็นต้องเพิ่มเติมในการเพิ่มและเอาเงินออก⁵. ดังนั้นพื้นที่บล็อกเดลต้าที่จำเป็นต่อผู้ใช้งานร่องน้ำ โดยสมมติว่าใช้งานmusig, คือการส่งออก taproot 43vB พร้อมกับ

การใช้จ่ายเส้นทางคีย์พาธ taproot 57.5vB รวม 100.5vB หากเราสมมติการใช้พื้นที่บล็อก 90% อีกครั้งเราจะได้รับ:

สุดท้ายนี้ โปรดทราบว่าการสลับช่อง Lightning ระหว่างกระเป๋าเงินสามารถทำได้ในธุรกรรมเดียวโดยการไว้วางใจกระเป๋าเงินถัดไปที่จะลงลายมอบอำนาจหลังจากเงินได้ถูกส่งไปยังที่อยู่การมอบอำนาจ หรือด้วยการสนับสนุนการปิดช่องใหม่แบบร่วมมือในทั้งสองกระเป๋าเงิน

แน่นอนว่ามีกรณีการใช้งานที่แข่งขันกันสําหรับ Bitcoin นอกเหนือจากช่อง Lightning และวิธีที่จะแปลเป็นอัตราค่าธรรมเนียมนั้นยากที่จะรู้ แต่ตัวเลขเหล่านี้ทําให้เรามีสวนบอลคร่าวๆ ที่ชี้ให้เห็นว่าด้วยเทคโนโลยีปัจจุบัน อย่างน้อยก็เป็นไปได้ในทางเทคนิคที่จะสนับสนุนผู้ใช้ Lightning ที่มีอํานาจอธิปไตยของตนเองหลายร้อยล้านคน

ภาพรวม L2

ตามคำจำกัดความของระบบ L2 ของเรา มีรูปแบบการออกแบบหลักสองรูปแบบที่ถูกพูดถึงในชุมชนการพัฒนา Bitcoin:

1. ช่องทาง
2. UTXO เสมือน

ในรูปแบบของช่องทางที่ Lightning เป็นตัวอย่างหลัก โปรโตคอลก้าวหน้าโดยการแลกเปลี่ยนธุรกรรมที่ล่วงละเมิดระหว่างฝ่ายที่อาจถูกขุดแต่ไม่ได้อยู่ใน "เส้นทางที่ดีที่สุด" ธุรกรรมที่ล่วงละเมิดเหล่านี้แยก UTXO ระหว่างฝ่าย; ธุรกรรมเกิดขึ้นโดยการเปลี่ยนแปลงสมดุลของการแบ่งนั้นๆ ด้วยธุรกรรมที่ล่วงละเมิดใหม่ โดยเนื่องจากจะมีธุรกรรมที่ถูกต้องที่เป็นไปได้หลายรูปแบบที่ใช้ UTXO เดียวกัน จำเป็นต้องมีกลไกส่งเสริมให้แน่ใจว่าธุรกรรมที่ถูกต้องคือธุรกรรมที่จริงๆ ถูกขุด

ในรูปแบบการออกแบบ Virtual UTXO (V-UTXO) ซึ่ง Ark เป็นตัวอย่างที่โดดเด่นที่สุด V-UTXOs ถูกสร้างขึ้นผ่านพันธสัญญาหรือข้อตกลงหลายฝ่ายผ่านการสร้างธุรกรรมที่สามารถขุดเพื่อถอนเงิน V-UTXO เพียงฝ่ายเดียวโดยวางไว้ในห่วงโซ่ แต่ไม่ได้อยู่ใน "เส้นทางแห่งความสุข" ในแง่นั้น V-UTXO มีความคล้ายคลึงกับช่อง แต่แตกต่างจากช่องทาง V-UTXO schemes ทําธุรกรรมโดยใช้ V-UTXOs เองใน (แนวคิด) เดียว⁶ ธุรกรรมที่ลงนามล่วงหน้า

รูปแบบการออกแบบ "เส้นทางที่ดี" คือการใช้เส้นทางสคริปต์ "ทุกฝ่ายเห็นด้วย" เช่น N-of-N multisig; taproot ถูกออกแบบโดยเฉพาะสำหรับแนวคิดนี้ ทำให้เส้นทางคีย์สามารถเป็น N-of-N multisig ผ่าน musig ในกรณีที่ทุกฝ่ายเห็นด้วย เส้นทางที่ดีอนุญาตให้เหรียญถูกใช้ได้อย่างมีประสิทธิภาพ (และเป็นส่วนตัว)

น่าสนใจว่า เนื่องจาก virtual UTXOs เป็น "จริง" ในหลายๆ ด้าน การสร้างช่องทางบน virtual UTXOs เป็นเรื่องง่ายมากๆ โดยการสร้าง virtual UTXOs ที่ถ้าขุดเจอก็จะนำไปสู่การสร้าง UTXOs ที่จำเป็นสำหรับช่องทาง ดังนั้น virtual UTXO schemes เป็น

ชั้นที่ต่ำกว่าเล็กน้อยกว่าช่อง

ไฟฟ้าสาด

สถานะปัจจุบัน ที่นำมาใช้ในการผลิตเป็นเครือข่าย Lightning Network โดยมีพื้นฐานหลักบนมาตรฐาน BOLTs. Lightning เป็นการรวมกันของหลายสิ่งรวมถึงช่อง Lightning และ HTLCs, เครือข่ายการกําหนดเส้นทาง P2P, การกําหนดเส้นทางหัวหอม, มาตรฐานใบแจ้งหนี้ ฯลฯ โดยเฉพาะอย่างยิ่ง Lightning ไม่ใช่ระบบฉันทามติดังนั้นจึงไม่จําเป็นต้องใช้องค์ประกอบที่แตกต่างกันของ "ระบบ Lightning" ในลักษณะเดียวกันโดยผู้ใช้ทุกคน สําหรับวัตถุประสงค์ของบทความนี้เมื่อเราพูดว่า "Lightning" เราจะใช้มันในความหมายกว้าง ๆ รวมถึงการอัปเกรดที่คาดการณ์ได้ง่ายเป็นโปรโตคอล Lightning ปัจจุบัน (ทั่วไป) ที่ใช้กันอย่างแพร่หลาย

ตามที่กล่าวไว้ข้างต้นลักษณะสําคัญของ Lightning คือขีด จํากัด ความสามารถในการปรับขนาดของผู้ใช้ปลายทางเนื่องจากจําเป็นต้องมี UTXO อย่างน้อยหนึ่งรายการต่อผู้ใช้ ที่กล่าวว่าสําหรับองค์ประกอบการกําหนดเส้นทาง "หลัก" ของ Lightning - โหนด Lightning สาธารณะที่กําหนดเส้นทางธุรกรรมส่วนใหญ่ - ขีด จํากัด ความสามารถในการปรับขนาดเหล่านี้ไม่ได้กังวลมากนักเนื่องจาก Lightning ทํางานได้ดีหากมีผู้ใช้ปลายทางมากกว่าโหนดการกําหนดเส้นทางเนื่องจากแต่ละช่องทางสาธารณะที่ใช้สําหรับการกําหนดเส้นทางการชําระเงินสามารถรองรับธุรกรรมจํานวนมากต่อวินาทีได้อย่างง่ายดาย นี่คือเหตุผลที่ระบบ L2 ในอนาคตจํานวนมากคาดว่าจะเข้าร่วมในเครือข่าย Lightning ด้วย นอกจากนี้เรายังเห็นสิ่งนี้ว่าระบบ Not-Quite-L2 ที่มีอยู่เช่น Cashu พึ่งพาเครือข่าย Lightning อย่างมากเพื่อให้มีประโยชน์จริง ๆ : การใช้งานหลักของ Cashu น่าจะเป็นการส่งและรับการชําระเงิน Lightning

ช่องทางที่ไม่ต้องมีการโต้ตอบ

การก่อสร้างนี้ดีขึ้นจากช่องฟ้าแบบไฟฟ้าโดยใช้ OP_CTV เพื่อลดความต้องการในการมีปฏิสัมพันธ์ อย่างไรก็ตาม โดยที่มันไม่ดีขึ้นจาก 1-UTXO-per-user scaling limit เราจึงจะไม่พูดถึงมันต่อไป

Channel Factories

ที่นี่เรามีหลายฝ่ายเจรจาที่อยู่ n-of-n multisig เดียวพร้อมกับการใช้จ่ายธุรกรรมที่ multisig ที่อยู่เพื่อสร้าง n การแยกเงินทุนของ UTXO ที่แตกต่างกัน UTXOs เหล่านั้นจะใช้สําหรับช่องทางการชําระเงิน ช่องทางสามารถใช้กับการรักษาความปลอดภัยเดียวกันราวกับว่าพวกเขาถูกเปิดโดยตรงบนห่วงโซ่เพราะในกรณีที่จําเป็นต้องใส่สถานะช่องบนห่วงโซ่ธุรกรรมแยกสามารถขุดได้ สิ่งนี้อาจช่วยประหยัดพื้นที่ on-chain เมื่อช่องถูกปิดเนื่องจากฝ่าย n สามารถ - ในทางทฤษฎี - ปิดช่อง nn ทั้งหมดพร้อมกัน

ตั้งแต่ช่องโรงงานกำลังเจรจา UTXO ที่อาจถูกขุดแต่ไม่คาดหวังว่าจะได้รับการขุดจริงในเส้นทางที่ดีเพราะฉนั้นพวกเขาเป็นตัวอย่างที่เป็นพื้นฐานมากขึ้นของ V-UTXOs

โรงงานช่องโดยตนเองไม่จำเป็นต้องมีการ fork เพื่อเป็นไปได้ อย่างไรก็ตาม โรงงานช่องที่ง่ายที่อธิบายข้างต้นน่าจะไม่ Pratical ไปเกินจำนวนเล็กน้อยของฝ่ายเนื่องจากการประสานงานที่จำเป็นจริงๆเพื่อให้ได้ประโยชน์จากการขยายตัว ดังนั้น ข้อเสนอให้ซื้อเป็นช่องOP_Evictหรือ CTV (ผ่านต้นไม้ txout) มีเป้าหมายที่จะอนุญาตผลลัพธ์ที่ละเอียดอ่อนมากขึ้นที่สุดที่บุคคลเดียวสามารถถูกบังคับบนเชือกได้โดยไม่ต้องบังคับทุกคนในเชือกในครั้งเดียว

Eltoo/LN-Symmetry

เนื่องจาก Eltoo เป็นชื่อที่ทำให้สับสนมาก เราจะใช้ชื่อที่อัปเดตไว้คือ LN-Symmetry เท่านั้น

ในขณะที่ช่อง Poon-Dryja สนับสนุนให้มีการเผยแพร่สถานะที่ถูกต้องบนห่วงโซ่โดยการลงโทษสถานะที่ไม่ถูกต้อง LN-Symmetry อนุญาตให้อัปเดตสถานะที่ไม่ถูกต้องด้วยธุรกรรมเพิ่มเติมแทน สิ่งนี้มีข้อได้เปรียบในการลดความซับซ้อนของช่อง Lightning โดยการลบความซับซ้อนของบทลงโทษ อย่างไรก็ตามนี่น่าจะเป็นข้อเสียในสถานการณ์ที่ไม่น่าเชื่อถือเนื่องจากจําเป็นต้องมีบทลงโทษเพื่อกีดกันการฉ้อโกง

การเสมือนกันของ LN ต้องการ soft-fork เพื่อเปิดใช้งานSIGHASH_ANYPREVOUT, ซึ่งจำเป็นต้องอนุญาตให้ธุรกรรมของสถานะสามารถใช้จ่ายให้กับธุรกรรมสถานะอื่นในระหว่างการอัปเดต

ด้วยตัวเอง LN-Symmetry ไม่มีการปรับปรุงการปรับขนาดในช่องสัญญาณ Lightning ทั่วไป แต่ ผู้สนับสนุนได้วางข้อสนเทศ มันทําให้สิ่งต่าง ๆ เช่นโรงงานช่องทางง่ายต่อการใช้งาน

Ark

Ark ใช้แนวทางใหม่ในการปรับขนาดธุรกรรม: UTXOs เสมือนที่ถ่ายโอนได้อย่างสมบูรณ์ (V-UTXOs) ซึ่งสามารถรวมและแยกเป็นอะตอมได้⁷ ธุรกรรมนอกเครือข่าย ใน Ark ผู้ประสานงานส่วนกลาง Ark Service Provider (ASP) ให้ V-UTXOs สําหรับผู้ใช้ที่มีอายุการใช้งานที่กําหนดไว้เช่น 4 สัปดาห์ ช่วงเวลาเหล่านี้เรียกว่ารอบ V-UTXOs เหล่านี้ถูกสร้างขึ้นผ่านพูล txouts หนึ่งต่อรอบผ่านกลไกบางประเภทเช่น CTV เพื่อให้ txout แบบ on-chain เดียวสามารถกระทํากับต้นไม้ของ V-UTXOs ได้ การหมดอายุของรอบคือวิธีที่ Ark ได้เปรียบในการปรับขนาด: เมื่อสิ้นสุดรอบ pool txout จะปลดล็อก ทําให้ ASP สามารถใช้จ่ายเพียงฝ่ายเดียวด้วยลายเซ็นเดียวในธุรกรรมขนาดเล็ก เนื่องจากเวลาหมดอายุของรอบ V-UTXOs จะหมดอายุเมื่อพูล txouts ที่สร้างขึ้นหมดอายุ: ผู้ใช้ที่เป็นเจ้าของ V-UTXO จะต้องใช้จ่าย V-UTXO นั้นก่อนที่จะถึงเวลาหมดอายุของ pool txout หรือวางไว้บนห่วงโซ่ (ถอนฝ่ายเดียว)

ในการทําธุรกรรม V-UTXOs ระหว่างคู่สัญญาผู้ประสานงาน Ark จะร่วมลงนามในธุรกรรมที่ใช้ V-UTXOs อย่างน้อยหนึ่งรายการเพื่อให้ธุรกรรมนั้นใช้ได้ก็ต่อเมื่อ V-UTXOs อื่น ๆ อย่างน้อยหนึ่งรายการถูกสร้างขึ้นในรอบอื่น เมื่อรวมกับการหมดเวลาอย่างระมัดระวัง - ดูเอกสาร Ark สําหรับรายละเอียดทั้งหมด - การพึ่งพานี้คือสิ่งที่ทําให้การใช้จ่ายของ V-UTXO ไม่น่าเชื่อถือ: V-UTXO ไม่สามารถอ้างสิทธิ์ในเครือข่ายได้เว้นแต่จะมีการสร้าง V-UTXOs ใหม่ในธุรกรรมพูลอื่น มีวิธีที่เป็นไปได้สองสามวิธีในการใช้การพึ่งพานั้นจริง แต่รายละเอียดที่แน่นอนไม่เกี่ยวข้องกับวัตถุประสงค์ของบทความนี้

โปรดสังเกตว่าสิ่งนี้หมายความว่า ASP ที่กำหนดให้จะมีรอบที่กำลังเกิดขึ้นหลายรอบพร้อมกัน รอบใหม่จะถูกสร้างขึ้นอย่างต่อเนื่องเพื่อให้เงินในรอบที่มีอยู่สามารถถูกโอนไปในรอบใหม่ แต่รอบที่มีอยู่จะเกี่ยวข้องกับรอบใหม่โดยทั่วไปจะหมดอายุหลังจากรอบใหม่ และการสร้างการทำธุรกรรมใหม่

เศรษฐศาสตร์อาร์ค

เมื่อ V-UTXO ถูกใช้จ่าย ASP จะต้องให้ BTC ที่ตรงกันใน pool txout ใหม่ที่แทนรอบใหม่ แต่พวกเขาไม่สามารถกู้คืนค่าของ V-UTXO ที่ใช้จ่ายจนกว่ารอบจะหมดอายุ ดังนั้นเศรษฐศาสตร์ของ V-UTXO ที่ใช้จ่ายมีค่าใช้จ่ายเนื่องจากความสามารถในการให้เงินสดที่ ASP ต้องให้

โดยเฉพาะค่าใช้จ่ายจะเกิดขึ้นเมื่อใช้ V-UTXO ในขณะที่ V-UTXO ยังไม่สามารถใช้งานได้ แต่ก็แสดงถึง UTXO ที่มีศักยภาพจริงที่สามารถใส่ onchain เพื่อถอนเงินเพียงฝ่ายเดียว ผู้ใช้เป็นเจ้าของเงินเหล่านั้น อย่างไรก็ตามในการใช้ V-UTXO ASP จะต้องสร้างพูล txout ใหม่โดยใช้เงินที่ ASP ได้รับจากที่อื่นในขณะที่เงินใน V-UTXO ที่ใช้ไปจะไม่สามารถใช้ได้กับ ASP จนกว่าจะถึงเวลาหมดอายุ

ดังนั้น การใช้จ่าย V-UTXO ต้องการสินเชื่อระยะสั้น การยืมเงินเพื่อครอบคลุมช่วงเวลาระหว่างตอนนี้และเมื่อรอบหมดอายุ นี่หมายความว่าค่าสินทรัพย์ที่ใช้จ่าย V-UTXO จริง ๆ ลดลงเมื่อ V-UTXO มีอายุมากขึ้นและเวลาหมดอายุเข้าใกล้ขึ้น โดยทฤษฎีบางอย่าง จะลดลงถึงศูนย์เมื่อรอบสิ้นสุดท้าย

โปรดจำไว้ว่าค่าใช้จ่ายในการใช้ V-UTXO เกี่ยวข้องกับขนาดรวมของ V-UTXO ที่ใช้ไป ไม่ได้เกี่ยวข้องกับจำนวนที่จ่ายให้ผู้รับ นี่หมายความว่ากระเป๋าเงินที่มีจุดประสงค์ในการทำธุรกรรม V-UTXO โดยตรง (เปรียบเสมือนการจัดการ V-UTXO เพียงหนึ่งเพื่อวัตถุประสงค์ เช่น หนึ่งช่องทางการจ่ายเงินที่ใช้ V-UTXO) ต้องทำการแบ่งปันเงินใน V-UTXOs ได้อย่างไร้ค่าตอบแทน การแบ่งปันเงินใน V-UTXOs หลายรายการจะทำการตรงกันข้าม ซึ่งไม่เหมือนกับเศรษฐศาสตร์ของ Bitcoin ในเครือข่ายหรือการทำธุรกรรม Lightning

ต้นทุนสภาพคล่องนี้คืออะไร? ในขณะที่เขียนกระเป๋าเงิน Lightning Phoenix เรียกเก็บค่าธรรมเนียม 1% เพื่อสํารองสภาพคล่องของช่องเป็นเวลา 1 ปี ที่เลวร้ายที่สุดฟีนิกซ์จะต้องผูกเงินของพวกเขาเป็นเวลา 1 ปี อย่างไรก็ตามนั่นถือว่าไม่ได้ใช้สภาพคล่อง เป็นไปได้ค่อนข้างมากที่ต้นทุนของเงินทุนสําหรับฟีนิกซ์นั้นสูงกว่าจริง ๆ และพวกเขาสมมติว่าลูกค้าโดยเฉลี่ยใช้สภาพคล่องที่เข้ามาในเวลาน้อยกว่าหนึ่งปี ฟีนิกซ์ยังได้รับเงินจากค่าธรรมเนียมการทําธุรกรรมซึ่งอาจอุดหนุนสภาพคล่องของช่อง ในที่สุดฟีนิกซ์อาจไม่ทํากําไร!

อัตราตั๋วเงินคลังสหรัฐทําให้เรามีการประมาณการอีกครั้ง ในขณะที่เขียนอัตราตั๋วเงินคลัง 3 เดือนอยู่ที่ประมาณ 5% ต่อปี เนื่องจากมีข้อโต้แย้งว่าอัตรานี้สูงเกินจริงเนื่องจากดอลลาร์สหรัฐเป็นเงินเฟ้อเราจะถือว่าต้นทุนสภาพคล่องสําหรับกองทุน BTC สกุลเงินคือ 3% ต่อปีสําหรับการวิเคราะห์ของเรา

หากช่วงรอบเป็น 4 สัปดาห์ นั่นหมายความว่าการทำธุรกรรมจะเริ่มต้นด้วยค่าความสะดวกสบายในการเป็นเงิน

,โดยสุดท้ายลดลงสู่ศูนย์ ในกรณีที่ผู้ใช้พยายามย้ายเงินของพวกเขาไปยังรอบใหม่สองสัปดาห์ก่อนรอบสิ้นสุด ผู้ใช้จ่ายประมาณ 1.5% ต่อปีในค่าความสามารถในการเหลืออยู่เพื่อให้ได้การจัดเก็บเงินของพวกเขาเอง ในทางกลับกัน หากผู้ใช้รอจนถึงตอนสุดท้าย⁸ค่าใช้จ่ายอาจเป็นเกือบศูนย์ โดยเสี่ยงต่อการพลาดเวลาหมดอายุ

ผู้ใช้อาจไม่เห็นว่านี่เป็นค่าใช้จ่ายที่เล็กน้อย และค่าใช้จ่ายนี้ถือว่าต้นทุนคงที่ของแต่ละรอบได้รับการลดลงโดยการแบ่งค่าธรรมเนียมการทำธุรกรรมและค่าใช้จ่ายอื่น ๆ ให้กับจำนวนผู้เข้าร่วมมาก

Imagine if fixed costs were not so insignificant. Assume that the ASP has 1000 users and pool txouts are created once an hour on average. In a 4-week period, there will be 672 on-chain transactions. This means that the ASP's users collectively have to pay for almost the same number of transactions as the users just to hold their funds! It would probably be cheaper for them to open their own Lightning channels, even though the ASP requires them to wait for an hour for confirmation.

บูตสตราปปิง อาร์ค

ASP ใหม่ที่มีผู้ใช้ไม่มากพบกับความลังเล: ไม่ว่า ASP rounds จะเกิดขึ้นน้อยหรือมาก ผู้ใช้ก็ต้องรอนานเพื่อให้มีรอบที่เสนอเพียงพอ V-UTXOs เพื่อให้ได้การขยายออกและการลดค่าธุรกรรมที่มีประโยชน์ หรือการทำธุรกรรมของ ASP pool ที่เกิดขึ้นบ่อยๆ โดยมีค่าธุรกรรมสูงที่ผู้ใช้จะต้องจ่าย ตามที่เราได้แสดงในส่วนก่อนหน้า มันสามารถใช้เวลานานในการคิดคำนวณการทำรอบบ่อยๆ และ underlying pool txouts ของพวกเขา

เนื่องจากรอบหมดอายุปัญหานี้จึงเป็นเรื่องต่อเนื่องซึ่งเลวร้ายยิ่งกว่าที่ช่อง Lightning ต้องเผชิญ: อย่างน้อยช่อง Lightning ก็มีประโยชน์ต่อไปอย่างไม่มีกําหนดทําให้สามารถเปิดช่องได้ในขณะนี้และตัดจําหน่ายทีละน้อยในช่วงหลายเดือน ประการที่สองเนื่องจากรอบหมดอายุจึงมีความยืดหยุ่นน้อยลงว่าเมื่อใดที่จะสร้าง txouts ใหม่ที่สนับสนุนรอบเหล่านี้: หากค่าธรรมเนียมสูงเป็นเวลาหนึ่งหรือสองสัปดาห์ผู้ใช้ที่พูล txouts กําลังจะหมดอายุไม่มีทางเลือกอื่นนอกจาก (รวม) จ่ายค่าธรรมเนียมสูงเหล่านั้นเพื่อรักษาการดูแลเงินทุนของพวกเขา ด้วยช่อง Lightning มีความยืดหยุ่นมากขึ้นว่าเมื่อใดควรเปิดช่องจริง

ในขณะที่ผู้เขียนของ Ark เริ่มต้นตั้งแต่แนวคิดที่มองโลกในแง่ดีเยี่ยมมากๆ โดยที่การรอรอบใหม่จะเกิดขึ้นทุกๆ ไม่กี่วินาที การเริ่มต้นต้นแรกจะต้องเกิดขึ้นกับกรณีการใช้งานที่สามารถรอหลายชั่วโมงเพื่อยืนยันธุรกรรมของ Ark ถ้าค่าธรรมเนียมการทำธุรกรรมไม่ได้รับการสนับสนุน

ปฏิสัมพันธ์

Non-custodial Ark เป็นโปรโตคอลแบบโต้ตอบสูง: เนื่องจาก V-UTXOs ของคุณหมดอายุคุณมีกําหนดเวลาที่ยากลําบากในการโต้ตอบกับ ASP ของคุณมิฉะนั้น ASP อาจเลือกที่จะรับเงินของคุณ การโต้ตอบนี้ไม่สามารถจ้างบุคคลภายนอกได้เช่นกัน: ในขณะที่ Lightning มี watchtowers ที่กีดกันคู่สัญญาจากการพยายามฉีกคุณออกแม้ว่าช่องของคุณจะไม่ได้ออนไลน์ก็ตาม - เจ้าของเหรียญ Ark ต้องใช้คีย์ส่วนตัวของตนเองเพื่อรีเฟรชเงินทุนโดยไม่ต้องไว้วางใจ สิ่งที่ใกล้เคียงที่สุดใน Ark to watchtowers คือการลงนามในธุรกรรมที่อนุญาตให้หอสังเกตการณ์ถอนเงินของคุณแบบ on-chain เพียงฝ่ายเดียวจนถึงเวลาหมดอายุซึ่งมีต้นทุนค่าธรรมเนียมการทําธุรกรรมที่สําคัญ

พิจารณาสิ่งที่เกิดขึ้นกับ V-UTXO หากเจ้าของออฟไลน์: หลังจากรอบหมดอายุ ASP จําเป็นต้องกู้คืนเงินทุนเพื่อรับสภาพคล่องกลับคืนมาสําหรับรอบต่อไป หากเจ้าของ V-UTXO ออฟไลน์การวาง V-UTXO on-chain นั้นมีค่าใช้จ่ายในการทําธุรกรรมที่สําคัญเนื่องจาก ASP จําเป็นต้องกู้คืนเงินทุนในหลายระดับของต้นไม้ V-UTXO ASP สามารถสร้าง V-UTXOs ที่ไม่ได้ใช้ในรอบใหม่ได้ แต่สิ่งนี้ไม่น่าเชื่อถือจากมุมมองของเจ้าของ V-UTXO เนื่องจากพวกเขาไม่สามารถใช้จ่าย V-UTXO เหล่านั้นได้โดยไม่ต้องรับข้อมูล⁹ จาก ASP ASP ยังสามารถบันทึก V-UTXOs ที่ไม่ได้ใช้เป็นยอดคงเหลือในการดูแล หรืออาจจะมีนโยบายยึดเงิน!

โดยส่วนตัวแล้วฉันสงสัยว่าด้วยค่าใช้จ่ายที่ไม่สําคัญในการควบคุมตนเองใน Ark ผู้ใช้หลายคนจะเลือก ASP แทนด้วยนโยบายการหมุนเวียนเงินเข้าสู่รอบใหม่และยอมรับโอกาสในการทุจริตเมื่อสิ้นสุดแต่ละรอบ สิ่งนี้ถูกกว่าการย้ายเงินในเชิงรุกเร็วพอที่จะรับประกันความปลอดภัยในกรณีที่พวกเขาไม่สามารถเปิดโทรศัพท์ได้ทันเวลาสําหรับกระเป๋าเงินเพื่อย้ายเงินไปยังรอบใหม่

อาร์คขั้นสูง

อาจจะเป็นไปได้ที่จะลดความต้องการในการเงินทุนของ Ark ผ่านพันธะที่ทันสมัยมากขึ้น หากมันเป็นสิ่งที่ทั่วไปที่การใช้เงินทุนจะถูกใช้ไปตอนกลางทางของรอบ ตัวอย่างเช่น ขอสมมติว่า 50% ของค่า V-UTXO ทั้งหมดใน pool txout ได้ถูกใช้ไปแล้ว ถ้า ASP สามารถแลกคืนส่วนนั้นของ pool txout ของรอบได้เท่านั้น พวกเขาสามารถกู้คืนเงินทุนได้เร็วขึ้น ลดต้นทุนเงินทุนโดยรวม ในขณะที่ยังไม่มีข้อเสนอที่แน่นอนเกี่ยวกับวิธีที่จะทำเช่นนี้ได้รับการเผยแพร่ แต่ดูเหมือนว่าน่าจะเป็นไปได้ด้วยพันธะที่ทันสมัยมากพอแล้ว มีความน่าจะเป็นมากที่ผ่านการตัดสินใจเกี่ยวกับ soft-fork ที่ช่วยเพิ่ม opcode ที่มีประโยชน์มากมายพร้อมกัน

อย่างเดียวกันผ่าน Sufficiently Advanced™ covenants โครงสร้างต้นไม้ txout ทั้งหมดอาจถูกแทนที่ด้วยรูปแบบการถอนแบบเลื่อนบนอาจเสนอการประหยัดพื้นที่ ในส่วนถัดไปเราจะพูดถึงเรื่องนี้ในส่วนอื่น ๆ เนื่องจากเทคนิคนี้เป็นประโยชน์ได้สำหรับรูปแบบอื่น ๆ

ปัญหาการดูแลในตอนท้ายของรอบเป็นอีกกรณีหนึ่งที่พันธสัญญาขั้นสูง™เพียงพอสามารถแก้ปัญหาได้: พันธสัญญาโดยเฉพาะอย่างยิ่งพันธสัญญาที่พิสูจน์ ZK สามารถบังคับให้ ASP สร้าง V-UTXO ที่ไม่ได้ใช้ทั้งหมดในรอบถัดไปเพื่อขจัดปัญหาการดูแลที่ย้อนกลับไปเมื่อสิ้นสุดรอบ ในขณะที่มันอาจจะเป็นไปไม่ได้ที่จะทําให้สิ่งนี้ไม่น่าเชื่อถือเนื่องจากผู้ใช้อาจต้องการข้อมูลบางอย่างจาก ASP เพื่อใช้ V-UTXO ในรอบใหม่ แต่ก็สามารถป้องกันไม่ให้ ASP ได้รับทางการเงินจากการฉ้อโกงกับผู้ใช้ออฟไลน์

การชําระค่าธรรมเนียม On-Chain ในการถอนเงินฝ่ายเดียว

เช่นเดียวกับ Lightning เศรษฐศาสตร์ของการชําระค่าธรรมเนียมแบบ on-chain และมูลค่าที่แท้จริงของ V-UTXO หลังจากค่าธรรมเนียมเป็นตัวกําหนดว่าการใช้งาน Ark เป็นไปตามคําจํากัดความของ L2 ของเราผ่านการถอนฝ่ายเดียวหรือการฉ้อโกงที่ไม่เป็นประโยชน์ต่อ ASP เราจะพูดถึงลักษณะเฉพาะของสิ่งนี้เพิ่มเติมเมื่อเราพูดถึงรูปแบบการออกแบบต้นไม้ txout

Validity Rollups

โครงสร้างคล้าย sidechain ขนาดใหญ่โดยทั่วไปเสนอให้ใช้เทคโนโลยีการพิสูจน์ความรู้เป็นศูนย์ (ZK) ในรูปแบบต่างๆเพื่อบังคับใช้กฎของห่วงโซ่ เทคโนโลยี ZK-proof เป็นความแตกต่างที่สําคัญระหว่างเทคโนโลยีการรวบรวมความถูกต้องและรูปแบบอื่น ๆ ของ sidechain: หากรูปแบบการพิสูจน์ ZK ใช้งานได้ความถูกต้องของธุรกรรมสามารถรับประกันได้โดยคณิตศาสตร์แทนที่จะไว้วางใจบุคคลที่สาม ด้าน "ความรู้เป็นศูนย์" ของการพิสูจน์ ZK ไม่ใช่ข้อกําหนดในกรณีการใช้งานนี้: มันโอเคอย่างสมบูรณ์หากหลักฐาน "รั่วไหล" ข้อมูลเกี่ยวกับสิ่งที่พิสูจน์ได้ มันเกิดขึ้นที่แผนการทางคณิตศาสตร์ส่วนใหญ่สําหรับการพิสูจน์ระดับนี้เกิดขึ้นเพื่อพิสูจน์ความรู้เป็นศูนย์

จากมุมมองของบิตคอยน์ เครื่องหมายการค้นหาความถูกต้องต้องมีสัญญา เนื่องจากเราต้องการสร้าง UTXO สำหรับระบบที่สามารถใช้ได้เฉพาะหากปฏิบัติตามกฎของระบบ นี่ไม่จำเป็นต้องเป็นกระบวนการที่กระจายอำนาจ หลายโครงการ validity rollup จริงๆ แล้วเป็นศูนย์กลางทั้งหมด พิสูจน์ rollup กำลังพิสูจน์ว่าตัวเลือกการทำธุรกรรมที่เป็นศูนย์กลางได้ปฏิบัติตามกฎสำหรับลำดับของธุรกรรมใด ๆ

ด้านข้อตกลง... เทคโนโลยีพิสูจน์ทราบศาสตร์ของ Zero-Knowledge ยังเป็นสิ่งใหม่มาก ๆ โดยการพัฒนายังคงทำอยู่อย่างสม่ำเสมอ ดังนั้นมันเป็นสิ่งที่สูงสุดที่จะเห็นรหัสคำสั่งใด ๆ ที่ถูกเพิ่มเข้าไปใน Bitcoin ที่ตรงไปตรงมาตรวจสอบรูปแบบพิสูจน์ ZK แบบเฉพาะเจาะจงใด ๆ แทน แทนที่นั้นมันได้รับการยอมรับโดยทั่วไปว่ารูปแบบเฉพาะจะใช้รหัสคำสั่งทั่วไปมากขึ้น โดยเฉพาะ OP_CAT เพื่อตรวจสอบ ZK-proofs ผ่านสคริปต์ เช่น ตัวอย่างเช่น StarkWare is การลงคะแนนเสียงที่จะได้รับการนำ OP_CAT ไปใช้งาน

Validity rollups เป็นหัวข้อที่มีศักยภาพใหญ่มาก โดยมีโครงการที่มีคุณค่าต่ำและมีความฮาป์มากมาย ซึ่งเราจะไม่พูดถึงมันเพิ่มเติมนอกเหนือจากการชี้แนะโอปคอดที่อาจทำให้กลุ่มการออกแบบนี้เป็นไปได้

BitVM

โดยคร่าว ๆ แล้ว BitVM เป็นวิธีในการสร้างช่องไฟแบบฟ้าผ่าระหว่างฝ่ายสองฝ่ายโดยที่กฎของช่องไฟถูกบังคับโดยพิสูจน์ที่ไม่รู้เรื่อง โดยเนื่องจากมันจริง ๆ ไม่จำเป็นต้องมีพันธบัญญัติที่จะนำมาใช้ใน Bitcoin ในปัจจุบัน และเนื่องจากมันไม่สามารถใช้โดยตรงในการสร้างระบบ L2 ที่ขยายตัวเกินขีดจำกัด 1-UTXO-per-user เราจึงจะไม่พูดถึงมันต่อไป

ช่องทางลำดับชั้น

แชนเนลแบบลําดับชั้น¹⁰มีเป้าหมายที่จะทำให้การปรับขนาดช่องทางเร็วและถูกกว่า: "ช่องทางชั้นบันไดทำให้ความจุของช่องทางเหมือนเป็น LN ทำให้สามารถใช้ได้กับบิตคอยน์" อย่างไรก็ตามพวกเขายังไม่เกินขีดจำกัดของ 1 UTXO-per-user อย่างพื้นฐาน และไม่ต้องการการเปลี่ยนแปลงใด ๆ ในโปรโตคอลบิตคอยน์อย่างใดอย่างหนึ่ง ดังนั้นเราจึงไม่ได้พูดถึงพวกเขาต่อไป ผู้สนับสนุนของพวกเขาควรที่จะดำเนินการสร้าง! พวกเขาไม่จำเป็นต้องขออนุญาตจากเราใด ๆ

CoinPool

CoinPool ช่วยให้ผู้ใช้หลายคนสามารถแบ่งปัน UTXO เดียวกัน โอนเงินระหว่างผู้ใช้ที่แตกต่างกัน และถอนเงินอย่างเดี่ยวอย่างเดียว หนังสือข้อเสนอเรื่อง CoinPool ต้องการคุณลักษณะ softfork ใหม่สามอย่าง คือ SIGHASH_ANYPREVOUT, SIGHASH_GROUP ที่อนุญาตให้ลายเซ็นเฉพาะ UTXO ที่เฉพาะเจาะจงเท่านั้น และ OP_MerkleSub เพื่อตรวจสอบการลบสาขาเฉพาะจากต้นไม้ Merkle; ส่วนหลังนี้ยังสามารถทำได้ด้วย OP_CAT ได้

ขณะนี้การพัฒนา CoinPool ดูเหมือนจะคงที่ไว้ โดยคอมมิตสุดท้ายในเว็บไซต์ข้อมูลของมันมีอายุถึงสองปีแล้ว

เครือข่าย Enigma

ในขณะที่ฉันถูกขอให้พูดถึงเครือข่าย Enigma ดูเหมือนจะขาดเอกสารเกี่ยวกับข้อเสนอจริงๆ ของมัน Bitfinex’sโพสต์บล็อกทำการยื่นคำร้องของเขาได้มากมาย; หน้า MIT ว่างเปล่า เนื่องจากโพสต์บล็อกไม่ได้ทําให้ชัดเจนว่าควรเกิดอะไรขึ้นเราจะไม่พูดถึงมันต่อไป

ข้อคิดที่ต้องพิจารณาใน Mempool

นโยบาย mempool ปัจจุบันใน Bitcoin Core ไม่เหมาะสําหรับระบบ L2 ที่นี่เราจะพูดถึงความท้าทายหลักบางอย่างที่พวกเขาเผชิญและการปรับปรุงที่อาจเกิดขึ้น

การปักหมุดธุรกรรม

เมื่อเท็จจริงเป็นการใช้เศรษฐศาสตร์ผู้ใช้เครื่องมือสร้างโจมตีการธุรกรรม การโจมตีการตรึงหมุนหมุนใช้เพื่ออธิบายสถานการณ์ที่ต่างหาก ที่ในบางกรณีใครบางคนจะได้ทำให้เกิดขึ้นโดยประมาณ ( หรือไม่ตั้งใจ) ทําให้ยากที่จะได้รับธุรกรรมที่ต้องการขุดเนื่องจากการออกอากาศก่อนหน้าของธุรกรรมที่ขัดแย้งกันซึ่งไม่ได้รับการขุด นี่เป็นการเอารัดเอาเปรียบทางเศรษฐกิจเพราะในสถานการณ์การปักหมุดธุรกรรมที่แท้จริงมีธุรกรรมที่พึงประสงค์ที่นักขุดจะได้กําไรหากพวกเขาขุดมัน ธุรกรรมการปักหมุดที่ขัดแย้งกันจะไม่ถูกขุดในระยะเวลาที่เหมาะสมหากเคย

ตัวอย่างที่ง่ายที่สุดของการปักหมุดมาจากข้อเท็จจริงที่ไม่มี RBF เต็มรูปแบบสามารถปิดการเปลี่ยนธุรกรรมได้ ดังนั้นเราสามารถมีธุรกรรมอัตราค่าธรรมเนียมต่ําโดยปิดการเปลี่ยนทดแทนซึ่งจะไม่ถูกขุดแต่ไม่สามารถแทนที่ได้ โดยพื้นฐานแล้ว 100% ของพลังแฮชได้แก้ไขปัญหานี้โดยการเปิดใช้งาน RBF เต็มรูปแบบและในขณะที่เขียน RBF แบบเต็มควรเปิดใช้งานโดยค่าเริ่มต้นใน Bitcoin Core รุ่นถัดไป (หลังจาก 11 ปีของความพยายามไม่สามารถแปลข้อความได้

นั่นทำให้เกิดปัญหาการตรึง BIP-125 Rule #3 pinning ที่เป็นปัญหาที่เกี่ยวข้องกับโปรโตคอล L2 ตัวเลือกหลักที่เหลืออยู่และที่ยังไม่ได้รับการแก้ไขใน Bitcoin Core สำหรับการอ้างอิง BIP-125 Rule #3 กล่าวไว้ดังนี้

ต้องมีธุรกรรมทดแทนเพื่อชำระค่าธรรมเนียมสูงสุดที่มากกว่า (ไม่

เพียงอัตราค่าธรรมเนียม) มากกว่าผลรวมของค่าธรรมเนียมที่ชําระโดยธุรกรรมทั้งหมดที่ถูกแทนที่

กฎนี้สามารถถูกใช้ในการกระจายส่งธุรกรรมการหมุนเวียนที่มีค่าธรรมเนียมต่ำและมีการใช้เงินที่เกี่ยวข้องกับโปรโตคอลหลายอัตรา (หรือกลุ่มของธุรกรรม) ตั้งแต่มีค่าธรรมเนียมต่ำ ธุรกรรมนี้จะไม่ถูกขุดในระยะเวลาที่เหมาะสม ถ้ามีการเกิดขึ้น แต่เนื่องจากมีค่าธรรมเนียมรวมสูง การแทนที่ด้วยธุรกรรมที่แตกต่างกันจึงไม่เป็นทางเลือกทางเศรษฐกิจ

กฎที่ 3 การติดหมุดสามารถแก้ไขได้ง่ายๆ ทางreplace-by-fee-rateและการแก้ไขนี้สามารถทำงานได้ในทุกสถานการณ์ แต่น่าเสียดายที่ไม่ชัดเจนว่า RBFR จะได้รับการนำไปใช้โดย Core ในอนาคตใกล้ ๆ เนื่องจากพวกเขาใช้ความพยายามที่มากมายในการแก้ไขบางส่วนที่ไม่ดีกว่าธุรกรรม TRUC/V3.

การชำระค่าธรรมเนียม: RBF, CPFP, SIGHASH_ANYONECANPAY, Anchors, และ Sponsorship

เนื่องจากอัตราค่าธรรมเนียมไม่สามารถคาดเดาได้ การชำระเงินที่เชื่อถือได้และประหยัดในสถานการณ์ที่ธุรกรรมถูกลงลายมือไว้ล่วงหน้าเป็นเรื่องยาก มาตรฐานทองคำสำหรับการชำระเงินค่าธรรมเนียมคือการใช้ RBF โดยเริ่มต้นด้วยการประมาณค่าต่ำสุด และแทนที่ธุรกรรมด้วยเวอร์ชันค่าธรรมเนียมสูงเมื่อมีความจำเป็นจนกว่าจะถูกขุด เช่น ซอฟต์แวร์ปฏิทิน OpenTimestamps ใช้ RBF ในทิศทางนี้มาเป็นเวลาหลายปีแล้ว และ LND เพิ่มการสนับสนุนสำหรับRBF ที่ตระหนักถึงเวลาสำหรับ v0.18.

RBF เป็นมาตรฐานทองคําสําหรับการชําระค่าธรรมเนียมเนื่องจากเป็นพื้นที่บล็อกที่มีประสิทธิภาพมากที่สุดในเกือบทุกแห่ง¹¹สถานการณ์: ธุรกรรมทดแทนไม่ต้องใช้ข้อมูลเพิ่มเติมหรือส่งออก เทียบกับสิ่งที่จำเป็นจะต้องใช้ถ้าค่าธรรมเนียมถูกทายเป็นครั้งแรก

ความมีประสิทธิภาพเป็นสิ่งที่สำคัญ เพราะความไม่ประสิทธิภาพในการชำระเงินค่าธรรมเนียมทำให้...การชำระเงินค่าธรรมเนียมที่ไม่ตรงกัน แหล่งรายได้ที่ทํากําไรได้สําหรับนักขุดรายใหญ่ นักขุดที่เล็กกว่ากระจายอํานาจไม่สามารถทํากําไรจากการชําระค่าธรรมเนียมนอกวงได้เนื่องจากทําไม่ได้และไร้ประโยชน์ในการจ่ายเงินให้กับนักขุดรายย่อยเพื่อรับธุรกรรมที่ได้รับการยืนยัน การชําระเงินค่าธรรมเนียมนอกวงยังดูเหมือนว่าจะเชิญปัญหา AML / KYC: ในปัจจุบันระบบการชําระเงินค่าธรรมเนียมนอกวงส่วนใหญ่ที่มีอยู่จริงในขณะนี้ต้องใช้กระบวนการ AML / KYC บางประเภทเพื่อชําระค่าธรรมเนียมยกเว้นที่โดดเด่นของ ตัวเร่ง mempool.spaceซึ่ง ณ วันที่เขียน (ส.ค. 2024) ยอมรับ Lightning โดยไม่มีบัญชี

เพื่อใช้ RBF โดยตรงในสถานการณ์ที่มีการทำธุรกรรมที่เซ็นล่วงหน้า คุณจำเป็นต้องทำการเซ็นล่วงหน้า fee-variants ที่ครอบคลุมช่วงค่าธรรมเนียมที่เป็นไปได้ทั้งหมด ในขณะที่นี้มีความเป็นไปได้มากในกรณีมากๆ เนื่องจากจำนวนของตัวแปรที่จำเป็นมักจะเล็กน้อย¹², จนถึงตอนนี้โปรโตคอล Lightning ซึ่งเป็นผลิตภัณฑ์หลัก และโปรโตคอลที่เสนอขึ้นอื่น ๆ — เลือกที่จะใช้Child-Pays-For-Parent (CPFP) โดยปกติจะผ่านเอาต์พุตสมอ

ความคิดเบื้องหลังของแองเกิลเอาต์พุทคือคุณเพิ่มเอาต์พุทหรือมากกว่าหนึ่งเอาต์พุทในธุรกรรมที่มีมูลค่าต่ำหรือศูนย์ โดยมีความตั้งใจที่จะชำระค่าธรรมเนียมผ่าน CPFP โดยการใช้เอาต์พุทเหล่านั้นในธุรกรรมรอง แน่นอนว่านี้เป็นวิธีที่ไม่เป็นประสิทธิภาพมากเมื่อใช้กับโปรโตคอลเช่น LN ที่มีธุรกรรมบนเชื่อมโยงขนาดเล็กแทบจะไม่สำคัญเพิ่มขนาดรวมทั้งหมดของธุรกรรมการมีสัญญา LN ที่ใช้รายการลงทุนชั่วคราว. มันจะกังวลน้อยลงเมื่อใช้โปรโตคอลที่ใช้ธุรกรรมขนาดใหญ่เช่นอะไรก็ตามที่ใช้ OP_CAT เพื่อดําเนินการตามพันธสัญญา

ปัญหาที่เห็นได้ชัดน้อยกว่ากับเอาต์พุตสมอคือความจําเป็นในการเก็บ UTXOs เพิ่มเติมเพื่อชําระค่าธรรมเนียมด้วย ในแอปพลิเคชัน "ไคลเอนต์" ทั่วไปนี่อาจเป็นภาระโดยรวมที่สําคัญเนื่องจากหากไม่มีเอาต์พุตสมอมักจะไม่จําเป็นต้องรักษา UTXO มากกว่าหนึ่งรายการ อันที่จริงมีแนวโน้มว่ากระเป๋าเงิน Lightning ที่เน้นผู้บริโภคที่มีอยู่บางส่วนมีความเสี่ยงต่อการโจรกรรมโดยด้านระยะไกลของช่องในสภาพแวดล้อมที่มีค่าธรรมเนียมสูงเนื่องจากไม่สามารถจ่ายค่าธรรมเนียมได้

SIGHASH_ANYONECANPAY สามารถใช้สําหรับการชําระค่าธรรมเนียมในบางกรณีโดยอนุญาตให้เพิ่มอินพุตเพิ่มเติมในธุรกรรมที่ลงนาม SIGHASH_SINGLE อนุญาตให้เพิ่มเอาต์พุตได้ Lightning ใช้สิ่งนี้สําหรับธุรกรรม HTLC ในขณะนี้การปฏิบัตินี้อาจเสี่ยงต่อการปักหมุดธุรกรรมหากไม่ได้รับการจัดการอย่างรอบคอบ¹³เนื่องจากผู้โจมตีสามารถเพิ่มอินพุตและ/หรือเอาต์พุตจํานวนมากลงในธุรกรรมเพื่อสร้างพินอัตราค่าธรรมเนียมสูง/ค่าธรรมเนียมต่ํา RBFR แก้ไขปัญหานี้ วิธีการที่ใช้ในธุรกรรม TRUC/V3 ไม่สามารถแก้ไขปัญหานี้ได้ รูปแบบการชําระค่าธรรมเนียมนี้ไม่มีประสิทธิภาพเท่ากับ RBF แต่สามารถมีประสิทธิภาพมากกว่าเอาต์พุตสมอ

ในที่สุดก็มีข้อเสนอแบบฟอร์กต่าง ๆ เพื่อเพิ่ม การสนับสนุนค่าธรรมเนียมระบบสำหรับโปรโตคอล Bitcoin ซึ่งจะทำให้ธุรกรรมสามารถระบุความเชื่อมโยงกับธุรกรรมอื่น ๆ โดยที่ธุรกรรมผู้สนับสนุนจะสามารถถูกขุดได้เฉพาะเมื่อธุรกรรมที่ได้รับการสนับสนุนก็ถูกขุดไปแล้ว (เป็นไปได้มากที่จะเกิดในบล็อกเดียวกัน) นี่สามารถเป็นอย่างมากที่จะมีประสิทธิภาพมากกว่า CPFP แบบดั้งเดิมเนื่องจากธุรกรรมผู้สนับสนุนสามารถระบุความเชื่อมโยงนั้นโดยใช้ vbytes น้อยกว่าขนาดของอินพุตของธุรกรรมมากมาย

การขับถ่ายจักรยาน

การโจมตีการขี่จักรยานทดแทน¹⁴ ใช้ประโยชน์จากการเปลี่ยนธุรกรรมเพื่อพยายามแทนที่ธุรกรรม L2 ที่ต้องการนานพอที่จะได้รับการขุดที่ไม่พึงประสงค์แทน โดยพื้นฐานแล้วการโจมตีแบบหมุนเวียนทดแทนเป็นทางเลือกแทนเทคนิคการปักหมุดธุรกรรมโดยมีจุดมุ่งหมายเพื่อป้องกันไม่ให้ธุรกรรมที่ต้องการซื่อสัตย์ถูกขุดนานพอที่จะอนุญาตให้มีการขุดธุรกรรมที่ไม่พึงประสงค์ไม่สุจริตแทน ซึ่งแตกต่างจากการโจมตีแบบปักหมุดธุรกรรมการโจมตีแบบหมุนเวียนทดแทนไม่สามารถเกิดขึ้นได้โดยบังเอิญ

ตัวอย่าง Canonical เทียบกับ Hashed-Time-Locked-Contract (HTLC) ในขณะที่มันง่ายที่จะคิดว่า HTLC เป็นสัญญาที่จะอนุญาตให้มีการทําธุรกรรมผ่านการเปิดเผยของ preimage หรือผ่านการหมดเวลา ในความเป็นจริงเนื่องจากข้อ จํากัด ของการเขียนสคริปต์ Bitcoin HTLC อนุญาตให้ทําธุรกรรมได้ตลอดเวลาผ่านการเปิดเผย preimage จากนั้นหลังจากหมดเวลานอกจากนี้ผ่านกลไกการหมดเวลา

การส่งเสริมการขับเคลื่อนการปั่นจักรยานทดแทนนี้ใช้ภาพบริวเฉียบหลังจากเวลาหมดอายุ เพื่อแทนที่ธุรกรรมที่พยายามแก้ไขผลลัพธ์ HLTC ผ่านกลไกสิ้นสุดเวลาโดยไม่ให้เหยื่อเรียนรู้ภาพบริวเฉียบ การโจมตีการส่งเสริมการปั่นจักรยานแบบนี้ประสบความสำเร็จโดยใช้เวลานานพอสำหรับ HTLC ของช่องทางที่แตกต่างในการหมดเวลา

ความท้าทายหลักในการใช้การถอนรองที่ได้กำไรคือการต้องเสียค่าใช้จ่ายในทุกรอบการถอนรอง การนำ Lightning implementation ที่ตระหนักถึงเวลาสิ้นสุดจะใช้ค่าธรรมเนียมสูงขึ้นเรื่อย ๆ โดยพยายามใช้ HTLC output ที่หมดอายุก่อน HTLC output ต่อไปหมดอายุตามลำดับ นอกจากนี้ ใครก็สามารถชนะการโจมตีโดยการถ่ายทอดธุรกรรมที่ถูกแทนที่ได้¹⁵เมื่อรอบการเปลี่ยนแทนเสร็จสิ้นแล้ว

เหมือนกับการตรึงการทำธุรกรรม การสร้างรอบอัตราการเปลี่ยนแปลงยังเป็นการประดิษฐ์ทางเศรษฐกิจของคนขุดเหมืองด้วย ณ ท้ายของทุกรอบอัตราการเปลี่ยนแปลงยังมีการทำธุรกรรมที่ถูกลบออกจาก mempools แต่ยังคงถูกต้องและสามารถขุดได้ ถ้าแต่เพียงแค่คนขุดเหมืองยังคงมีมันใน mempools ของพวกเขา

รูปแบบคุณลักษณะและ Fork อ่อน

ตอนนี้ที่เราได้ให้ภาพรวมของระบบ Layer 2 ที่ขึ้นอยู่กับ covenant และความท้าทายจาก mempool แล้ว เราจะพยายามสกัดข้อมูลนั้นออกมาเป็นชุดที่สำคัญของคุณสมบัติที่เกี่ยวข้องกับ soft fork (โดยเฉพาะ opcode ใหม่) และรูปแบบการออกแบบที่ระบบ Layer 2 เหล่านี้ใช้ร่วมกัน สำหรับข้อเสนอ soft fork เรายังจะพูดถึงความเสี่ยงทางเทคนิคและความท้าทายเฉพาะของข้อเสนอเพื่อเริ่มต้นใช้งานแต่ละข้อเสนอ

OP_หมดอายุ

เราจะได้รับสิ่งนี้ไปก่อน การเสนอ OP_Expire¹⁶ เป็นวิธีง่ายๆในการกําจัดการโจมตีด้วยการขี่จักรยานทดแทนโดยการแก้ไขปัญหาที่ต้นทาง: ความจริงที่ว่า HTLC สามารถใช้สองวิธีที่แตกต่างกันในคราวเดียว ในบริบทของระบบ L2 สิ่งนี้เกี่ยวข้องกับทุกสิ่งโดยใช้กลไกคล้าย HTLC และอาจเป็นกรณีการใช้งานอื่น ๆ OP_Expire จะทําให้ผลลัพธ์ของธุรกรรมไม่สามารถใช้จ่ายได้หลังจากช่วงเวลาหนึ่งทําให้เงื่อนไขการใช้จ่าย HTLC เป็นเอกสิทธิ์ที่แท้จริงหรือแทนที่จะเป็น "โปรแกรมเมอร์หรือ"

OP_Expire soft-fork จริง ๆ นั้น อาจประกอบด้วยคุณลักษณะสองอย่างที่คล้ายกัน คล้ายกับวิธีที่OP_CheckLockTimeVerifyและOP_CheckSequenceVerifyopcode มาในสองส่วน:

1. เขตสูงของการหมดอายุสำหรับธุรกรรม ที่น่าจะได้รับการนำมาใช้ในการเสริมสร้างรากองค์กร
2. คำสั่ง OP_Expire ที่ตรวจสอบว่าความสูงการหมดอายุถูกตั้งไว้อย่างน้อยที่ความสูงที่ต้องการ

ในขณะที่ OP_Expire เป็นสัญญาที่ยากจะมีคุณสมบัติเพียงใด แต่ดูเหมือนว่าจะมีประโยชน์สำหรับระบบ L2 ที่ขึ้นอยู่กับสัญญาหลายๆ อย่าง อย่างไรก็ตาม อาจจะไม่มีประโยชน์มากพอเนื่องจากว่าสามารถลดการรีเพรสตัวแทนได้ด้วยการกระจายขยายกิจกรรมที่เพียงใด¹⁵

ความท้าทายที่สำคัญมากๆ ในการใช้งาน OP_Expire คือ reorgs: ชุมชนทางเทคนิคของ Bitcoin ซึ่งเริ่มต้นด้วย Satoshi¹⁷ได้พยายามให้แน่ใจว่าโปรโตคอลความเห็น Bitcoin ถูกออกแบบให้หลังจาก deep reorg ธุรกรรมที่ถูกขุดก่อนหน้านี้สามารถขุดในบล็อกใหม่ได้ หลักการออกแบบนี้พยายามหลีกเลี่ยงสถานการณ์นิ้วร้องซึ่งจำนวนมากของเหรียญที่ได้รับการยืนยันกลายเป็นโมฆะถาวร - ซึ่งผู้คนที่พึ่งพาเหรียญเหล่านั้นจะสูญเสียเงิน - หากความล้มเหลวของความเห็น导致แถลงการณ์ที่ใหญ่

ในกรณีที่มีการจัดโครงสร้างใหม่ขนาดใหญ่ธุรกรรมที่ใช้การหมดอายุอาจไม่สามารถแก้ไขได้เนื่องจากความสูงหมดอายุถึง ข้อเสนอ OP_Expire เสนอให้ mitiGate ปัญหานี้โดยปฏิบัติต่อผลลัพธ์ของธุรกรรมที่ใช้วันหมดอายุคล้ายกับธุรกรรม coinbase นอกจากนี้ยังทําให้ไม่สามารถใช้จ่ายได้สําหรับ ~ 100 บล็อก

ข้อความประกอบธุรกรรมที่สำคัญในการใช้หมดอายุกำลังมาถึงความเห็นร่วมกันเกี่ยวกับว่าสำหรับทางเลือกนี้ยอมรับหรือไม่ หรือหากจำเป็นต้องใช้ ประเภทของธุรกรรมที่ OP_Expire จะมีประโยชน์เป็นสิ่งที่ใช้เวลานานในการจำกัดการใช้เงินของผู้ใช้ การเพิ่มเวลาในการจำกัดเวลาเหล่านี้ไม่เป็นที่พึงประสงค์ นอกจากนี้ การใช้เงินซ้ำกันอาจเป็นวิธีที่อื่นในการทำให้เหรียญเสียหายหลังจากการเรียงลำดับใหม่: ด้วยการใช้ RBF มากขึ้นและการใช้เอาต์พุตจำกัดที่ไม่มีกุญแจที่ยอมรับ การหมดอายุของการทำธุรกรรมจะสร้างความแตกต่างอย่างมีนัยสำคัญหรือไม่

SIGHASH_ANYPREVOUT

BIP-118เสนอวิธีการแซนท์สองวิธีใหม่ ทั้งสองวิธีไม่เชื่อมโยงกับ UTXO ที่ระบุให้เสียเงิน SIGHASH_ANYPREVOUT ที่ (โดยสรุป) เชื่อมโยงกับ scriptPubKey แทน และ SIGHASH_ANYPREVOUTANYSCRIPT ที่อนุญาตให้ใช้สคริปต์ใดก็ได้ ตามที่ได้พูดถึงข้างต้น นี่เป็นการเสนอเพื่อใช้งานโดย LN-Symmetry เพื่อหลีกเลี่ยงการต้องลงลายมือแยกกันสำหรับทุกสถานะของช่องทางก่อนหน้าที่อาจจะต้องตอบสนอง

SIGHASH_ANYPREVOUT ยังมีความเป็นสมควรในกรณีที่เราต้องการใช้ pre-signed RBF fee-rate variants ร่วมกับ pre-signed transactions โดยความจริงที่ลายเซ็นต์ไม่ได้ขึ้นอยู่กับ txid ที่เฉพาะเจาะจงการระเบิดความหลากหลายของอัตราค่าธรรมเนียม. อย่างไรก็ตาม ข้อเสนอ BIP-118 ปัจจุบันไม่ได้พิจารณากรณีใช้นี้และอาจเข้ากันไม่ได้เนื่องจาก SIGHASH_ANYPREVOUT ที่เสนอขึ้นยังไม่ได้รับการยอมรับในค่าของ UTXO ด้วย

การคัดค้านครั้งแรกของ SIGHASH_ANYPREVOUT คือความคิดที่ว่ากระเป๋าเงินจะทําให้ตัวเองมีปัญหาโดยใช้วิธีที่ไม่เหมาะสม ปัญหาคือเมื่อมีการเผยแพร่ลายเซ็น SIGHASH_ANYPREVOUT เดียวแล้วสามารถใช้เพื่อใช้จ่าย txout ใด ๆ กับสคริปต์ที่ระบุ ดังนั้นหากเอาต์พุตที่สองที่มีสคริปต์เดียวกันถูกสร้างขึ้นโดยไม่ได้ตั้งใจ SIGHASH_ANYPREVOUT อนุญาตให้มีการโจมตีซ้ําเล็กน้อยเพื่อขโมยเหรียญเหล่านั้น อย่างไรก็ตามเนื่องจากมีปืนเท้าอื่น ๆ อีกมากมายที่มีอยู่ในกระเป๋าเงินและการใช้งาน L2 ความกังวลนี้ดูเหมือนจะหมดไป

ขณะนี้ ชุมชนทางเทคนิคทั่วไปดูเห็นด้วยในเรื่องการนำ BIP-118 มาใช้ อย่างไรก็ตาม ตามที่ได้ถูกกล่าวถึงในการอภิปรายของเราเกี่ยวกับ LN-Symmetry มีการโต้วาทีเกี่ยวกับว่า กรณีการใช้หลักของมัน คือ LN-Symmetry จริงๆ แล้วเป็นไอเดียที่ดีหรือไม่

OP_CheckTemplateVerify

เรื่องข้อเสนอ opcode ประเภทพันธบัตรของเราครั้งแรก OP_CheckTemplateVerify - หรือที่เรียกว่า 'CTV' อย่างทั่วไป - มีเป้าหมายที่จะสร้าง opcode พันธบัตรที่จำกัดเฉพาะโดยการทำเพียงสิ่งเดียว: การหาค่าแฮชของธุรกรรมการใช้จ่ายในวิธีที่ระบุที่ไม่รับผิดชอบต่อ UTXO ของข้อมูลนำเข้า และตรวจสอบการย่อยออกมากับสมาชิกสุดยอดของสแต็ก นี้อนุญาตให้ธุรกรรมการใช้จ่ายถูกจำกัดล่วงหน้าโดยทำให้ห้ามการจำกัดพันธบัตรที่วนซ้ำจริงได้

ทำไมสัญญากู้ซ้ำไม่สามารถทำได้ใน CTV? เพราะฟังก์ชันแฮช: CTV ตรวจสอบธุรกรรมการใช้จ่ายกับแฮชเทมเพลต และไม่มีทาง¹⁸ ของการสร้างเทมเพลตที่มี CTV ด้วยแฮชของตัวเอง

อย่างไรก็ตาม สิ่งนี้ไม่จำเป็นต้องเป็นข้อ จริงๆ แล้วคุณสามารถทำการแฮชลิงค์เทมเพลต CTV ไปถึงระดับของการทำธุรกรรมที่หลายหมื่นรายการในไม่กี่วินาทีบนคอมพิวเตอร์รุ่นใหม่relative nSequence timelocksและขนาดบล็อกที่ถูกจำกัดจริง ๆ ที่กำลังจะสิ้นสุดของโซ่ดังกล่าว สามารถทำให้ใช้เวลาหลายพันปีได้อย่างง่ายดาย

ข้อเสนอ CTV ปัจจุบันในBIP-119 มีโหมดการแฮชเพียงโหมดเดียวที่เรียกว่า DefaultCheckTemplateVerifyHash ซึ่งโดยพื้นฐานแล้วจะทุ่มเทให้กับทุกแง่มุมของธุรกรรมการใช้จ่ายในแฮชเทมเพลต จากมุมมองในทางปฏิบัติหมายความว่าในหลาย ๆ สถานการณ์กลไกเดียวที่มีอยู่สําหรับการชําระค่าธรรมเนียมคือ CPFP ดังที่ได้กล่าวไว้ข้างต้นนี่เป็นปัญหาที่อาจเกิดขึ้นเนื่องจากทําให้การชําระค่าธรรมเนียมนอกวงเป็นการประหยัดต้นทุนที่ไม่สําคัญในกรณีที่ธุรกรรมที่ใช้ CTV มีขนาดเล็ก

สามารถบอกได้โดยเป็นความเป็นธรรมที่ CTV มีการสนับสนุนที่กว้างขวางที่สุดในหมู่ชุมชนทางเทคนิคเมื่อเทียบกับข้อเสนอโอปโคดการสัญญาใด ๆ เนื่องจากความง่ายของมันและการใช้งานที่หลากหลายมาก

LNHANCE

หนึ่งในข้อเสนอที่จะนำ CTV มาใช้งานคือการรวมมันกับออปคอดสองตัว คือ OP_CheckSigFromStack(Verify) และ OP_InternalKey ปัญหาคือ ณ ขณะที่เขียนอยู่เอกสารคำอธิบายใน pull-req นั้นและ BIPs ที่เกี่ยวข้องไม่เพียงพอที่จะสามารถเห็นเหตุผลที่เหมาะสมกับข้อเสนอนี้ได้ BIPs ไม่มีเหตุผลเกี่ยวกับว่าออปคอดทั้งสองคืออะไรที่คาดหวังให้ทำงานจริงในเชิงประยุกต์ อย่างน้อยตัวอย่างสคริปต์ที่ละเอียดหรือสคริปต์ตัวอย่างในโลกจริงไม่ได้ถูกเสนอ

ในขณะที่ผู้เขียนมีเหตุผลที่ดีสำหรับข้อเสนอของพวกเขาอาจจะเป็นเช่นนั้น ความรับผิดชอบอยู่ที่พวกเขาที่จะอธิบายเหตุผลเหล่านั้นและยืนยันมันอย่างถูกต้อง ดังนั้นเราจึงจะไม่พูดถึงมันต่อไป

OP_TXHASH

คล้ายกับ CTV ข้อเสนอนี้สามารถทำให้ฟังก์ชันงานคอเวแนนท์ที่ไม่เรียกตัวเองได้โดยการแฮชข้อมูลจากธุรกรรมการใช้จ่าย ในขณะที่ CTV ข้อเสนอนี้ TXHASH ให้กลไก “ตัวเลือกฟิลด์” ที่ช่วยให้ยืดหยุ่นในการจำกัดธุรกรรมการใช้จ่ายอย่างแน่นหนา ความยืดหยุ่นนี้ทำให้เกิดเป้าหมายหลักสองอย่าง

1. เปิดให้เพิ่มค่าธรรมเนียมในธุรกรรมโดยไม่ทำให้โปรโตคอล multi-tx ขาดการทำงาน
2. โปรโตคอลแบบ Multi-user ที่ผู้ใช้จำกัดเฉพาะอินพุตและเอาต์พุตของตนเองเท่านั้น

ปัญหาหลักของ OP_TXHASH คือกลไกตัวเลือกฟิลด์เพิ่มความซับซ้อนมากเกินไป ทำให้การทบทวนและการทดสอบมีความท้าทายมากขึ้นเมื่อเปรียบเทียบกับข้อเสนอ CTV ที่ง่ายมากขึ้น ณ ขณะนี้ยังไม่มีการวิเคราะห์การออกแบบมากมายว่ากลไกตัวเลือกฟิลด์จะเป็นประโยชน์อย่างไรและจะถูกใช้อย่างไรอย่างแน่นอน ดังนั้นเราจะไม่พูดถึงมันต่อไป

OP_CAT

ตัวดำเนินการการเชื่อมต่อซึ่งเชื่อมต่อสององค์ประกอบสูงสุดของสแต็คและผลลัพธ์ที่ถูกต่อมันกลับมาอยู่ในสแต็ค บิตคอยน์เดิมที่จัดส่งพร้อมกับ OP_CAT เปิดใช้งาน แต่ซาโตชิ ถูกลบออกไปอย่างเงียบ ๆ เมื่อปี 2010, อาจเป็นเพราะความจริงที่การนำมาใช้งานครั้งแรกมีช่องโหว่ต่อการโจมตีด้วยการปฏิบัติที่ไม่อาจเข้าถึงได้เนื่องจากขนาดขององค์ประกอบสคริปต์ที่ได้มีข้อจำกัด พิจารณาสคริปต์ต่อไปนี้:

DUP CAT DUP CAT ...

โดยไม่มีการจำกัดขนาดองค์ประกอบ การทำซ้ำ DUP CAT ทุกครั้งจะทำให้ขนาดขององค์ประกอบบนสุดเพิ่มขึ้นสองเท่า โดยสุดท้ายจะใช้หมดหน่วยความจำที่มีอยู่ทั้งหมด

การต่อเชื่อมเพียงพอที่จะนำมาใช้ในการดำเนินการหลายประเภทของคำสัญญา รวมถึงคำสัญญาที่วนซ้ำ โดยการดำเนินการต่อไปนี้:

1. รวบรวมธุรกรรมบางส่วนโดยไม่มีข้อมูลพยานบนสแต็กด้วยการเรียก OP_CAT อย่างน้อยหนึ่งรายการ (และจําเป็นต้องใช้ตรรกะเฉพาะพันธสัญญาใดก็ตาม)
2. ตรวจสอบว่าธุรกรรมบนสแต็กตรงกับธุรกรรมการใช้จ่าย

ดังที่เป็นจริง โดยการใช้เครื่องหมายของลายเซ็นของ Schnorr อย่างไม่สุภาพสำหรับขั้นตอนที่สอง สามารถทำได้ด้วย OP_CheckSig ผ่านลายเซ็นที่สร้างด้วยความระมัดระวัง อย่างไรก็ตามมีความเป็นไปได้มากกว่า OP_CAT soft-fork จะถูกผสมกับ OP_CheckSigFromStack ทำให้สามารถทำขั้นตอนที่สองได้โดยการตรวจสอบว่าลายเซ็นบนสแต็กเป็นลายเซ็นที่ถูกต้องสำหรับธุรกรรม¹⁹แล้วนำลายเซ็นเดียวกันนั้นมาใช้กับ OP_CheckSig เพื่อตรวจสอบว่าธุรกรรมการใช้จ่ายตรงกับที่ตราสารลงนาม²⁰

ความจริงที่ว่าเราจําเป็นต้องรวบรวมธุรกรรมโดยไม่มีข้อมูลพยานเป็นจุดสําคัญ: พันธสัญญาจําเป็นต้องตรวจสอบสิ่งที่ธุรกรรมทํา - อินพุตและเอาต์พุต - ไม่ใช่ข้อมูลพยาน (ถ้ามี) ที่ทําให้ถูกต้องจริง

จำกัดขนาดสคริปต์โมดูล การผสมผสานระหว่าง OP_CAT และ OP_CheckSigFromStack เพียงพอในการสร้างสัญญาประเภทต่าง ๆ รวมถึงสัญญาที่เกี่ยวข้องกัน เมื่อเทียบกับการแก้ปัญหาที่มีประสิทธิภาพมากขึ้นเช่น CTV มันจะมีค่าใช้จ่ายมากกว่า แต่ความแตกต่างในต้นทุนน้อยกว่าที่คุณคาดหวัง!

โดยประมาณแล้วการใช้ OP_CAT เพื่อทำเช่นนี้ต้องการให้ส่วนที่ไม่ใช่ witness ของธุรกรรมใช้จานวนพอดีบนสแต็กผ่าน witness สำหรับ CTV use-cases ที่ตรงตามกฎหมาย เช่น txout trees ธุรกรรมในการใช้จะไม่มีข้อมูล witness เลย เนื่องจากพื้นที่ witness ได้รับส่วนลด 75% นั่นเพิ่มค่าธรรมเนียมธุรกรรมที่มีประโยชน์ของเด็กธุรกรรมเราเพียง 25% เท่านั้น ไม่แย่อย่างสิ้นเชิง!

OP_CATเกินไปหรือไม่?

น่าจะเป็นอุปสรรคทางการเมืองและเทคนิคที่สำคัญที่สุดในการใช้ OP_CAT: มันยากมากที่จะทำนายว่าการใช้งานจะเป็นไปอย่างไรโดย OP_CAT และหนึ่งครั้งที่ "แมว" ออกมาจากถุงแล้ว มันยากมากที่จะใส่มันกลับ

ตัวอย่างที่ดีคือ OP_CAT ที่กล่าวถึงว่าเพียงพอต่อความเป็นไปได้อย่างมีประสิทธิภาพและปลอดภัยการตรวจสอบ STARK ที่นำมาใช้ในสคริปต์บิตคอยน์. เนื่องจาก STARKs สามารถพิสูจน์ข้อความทั่วไปได้อย่างมากทําให้สามารถใช้ STARKs ได้อย่างมีประสิทธิภาพจึงมีผลกระทบอย่างมีนัยสําคัญที่เกินขอบเขตของระบบ L2 เนื่องจากจะช่วยให้สามารถสร้างระบบต่างๆได้บน Bitcoin ข้อโต้แย้งที่แข็งแกร่งต่อ OP_CAT คือกรณีการใช้งานเหล่านี้อาจไม่เป็นผลดีต่อผู้ใช้ Bitcoin ทั้งหมด

การสร้างค่า Miner Extractable Value ที่เป็นอันตรายที่หนึ่งเป็นปัญหาที่สำคัญที่มีความเป็นไปได้สูง, เรียกว่า "MEV ที่ต่อเนื่อง" (MEVil) โดย Matt Corallo. กล่าวโดยย่อ MEVil คือสถานการณ์ใด ๆ ที่นักขุด/พูลขนาดใหญ่สามารถดึงมูลค่าเพิ่มได้โดยใช้กลยุทธ์การขุดธุรกรรมที่ซับซ้อน — นอกเหนือจากการเพิ่มค่าธรรมเนียมทั้งหมดให้สูงสุด — ซึ่งเป็นไปไม่ได้สําหรับนักขุด/พูลขนาดเล็กที่จะนํามาใช้ ความซับซ้อนเฉือนของเครื่องมือทางการเงินที่มีศักยภาพซึ่งสามารถสร้างได้ด้วย OP_CAT ทําให้การพิจารณา MEVil ยากมาก MEVil ที่สําคัญได้ปรากฏบน Bitcoin แล้วจากโปรโตคอลการประมูลโทเค็น โชคดีที่กรณีเฉพาะนั้นพ่ายแพ้ผ่านการยอมรับ RBF เต็มรูปแบบ

นอกจากศักยภาพของ MEVil ยังมีกรณีใช้ OP_CAT ที่เป็นอันตรายได้หลายกรณี เช่น ข้อเสนอ Drivechains ได้ ตรวจสอบที่นี่, และถือว่าเป็นอันตรายต่อ Bitcoin อย่างแพร่หลายเชื่อว่าเป็นไปได้เพื่อให้เกิดการดำเนินการ Drivechain's ด้วย OP_CAT ตัวอย่างอื่น ๆ คือการเสนอแบบทอเทรดเหรียญ เมื่อไม่สามารถป้องกันจากการนำมาใช้ได้โดยทั่วไป ตัวอย่างเช่น Taproot Assetsการตรวจสอบทางด้านไคลเอ็นต์มีข้อเสนอให้นําไปใช้กับ OP_CAT ในรูปแบบที่อาจดึงดูดผู้ใช้ปลายทางได้มากขึ้นในขณะเดียวกันก็ใช้พื้นที่บล็อกมากขึ้นซึ่งอาจแซงหน้าธุรกรรม Bitcoin ที่ "ถูกกฎหมาย" กรณีการใช้งานเหล่านี้อาจก่อให้เกิดปัญหาทางกฎหมายเนื่องจากความถี่ในการใช้โปรโตคอลโทเค็นสําหรับการฉ้อโกงทางการเงิน

การแฮชแบบเพิ่มเติม

สำหรับสัญญา OP_CAT จะถูกใช้โดยส่วนใหญ่เพื่อต่อข้อมูลและจากนั้นทำการแฮช วิธีอีกวิธีในการบรรลุเป้าหมายเดียวกันนี้คือด้วยรหัสคำสั่งแฮชแบบเพิ่มทีละน้อยที่ใช้ SHA256 midstate ของแบบใดแบบหนึ่ง และแฮชข้อมูลเพิ่มเข้าไป; SHA256 เองทำงานบนบล็อกขนาด 64 ไบต์ มีการออกแบบหลายรูปแบบที่เป็นไปได้สำหรับรหัสคำสั่งแฮชแบบเพิ่มทีละน้อย

การตัดสินใจออกแบบที่สําคัญประการหนึ่งคือการเปิดเผยไบต์กลางที่แท้จริงบนสแต็คในรูปแบบบัญญัติบางประเภทหรือแสดงในประเภทรายการสแต็คทึบแสงชนิดใหม่ซึ่งค่าไบต์จริงไม่สามารถจัดการได้โดยตรง SHA256 ถูกระบุสําหรับเวกเตอร์การเริ่มต้นเฉพาะคงที่และดูเหมือนว่าจะไม่ทราบว่าคุณสมบัติการเข้ารหัสของ SHA256 เป็นจริงหรือไม่หากอนุญาตให้ใช้เวกเตอร์กลาง / การเริ่มต้นโดยพลการ

แน่นอน เนื่องจากการทำ incremental hashing สามารถทำได้เกือบทุกอย่างที่ OP_CAT สามารถทำได้ แต่มีประสิทธิภาพมากขึ้น มันก็มีความกังวลเหมือนกันเกี่ยวกับ OP_CAT ที่มีความทรงจำมากเกินไป

การฟื้นคืนสคริปต์

OP_CAT เป็นหนึ่งในรหัสโอป์คอดที่ซาโตชิปิดใช้งาน นอกจากที่จะเรียกคืน OP_CAT รัสตี้ รัสเซลกำลัง²¹เพื่อที่จะคืนค่าสคริปต์ของบิตคอยน์ให้เป็น "วิสัยทัศน์ต้นฉบับของ Satoshi" โดยการเปิดใช้งานส่วนใหญ่ของแอปคอดดังกล่าว การเพิ่มขีดจำกัดการโจมตีด้วยการปิดใช้งานและเพิ่มส่วนของซอฟต์ฟอร์คเดียวกันอีกไม่กี่ส่วน โดยเฉพาะอย่างยิ่ง OP_CheckSigFromStack น่าจะมี

แม้ว่า OP_CAT คนเดียวจะทำให้ covenants (recursive) เป็นไปได้ แต่การฟื้นฟู “สคริปต์” เต็มรูปแบบจะทำให้ covenants ที่ซับซ้อนขึ้นเป็นไปได้มากขึ้น - และง่ายต่อการดำเนินการ - เนื่องจากส่วนของการใช้จ่ายสามารถถูกจัดการโดยตรง ตัวอย่างเช่น คุณสามารถจินตนาการถึงสคริปต์ covenant ที่ใช้คำสั่งลำดับทางคณิตศาสตร์เพื่อให้มีค่ารวมของ txouts ในการทำธุรกรรมตรงกับคุณสมบัติที่ต้องการได้

อีกครั้ง การฟื้นฟูสคริปต์เสื่อมทั้งหมดเกี่ยวกับปัญหาเดิม และอื่น ๆ เกี่ยวกับการมีอำนาจมากเกินไปที่ OP_CAT เพียงอย่างเดียว

ความเรียบง่าย

คล้ายกับ Script Revival ความง่ายเป็นสิ่งที่เกี่ยวข้องกับ L2 และ covenants โดยทำให้เป็นไปได้ที่จะทำอะไรก็ได้ ไม่เหมือนกับ Script Revival ฟอร์ค Simplicity จะเพิ่มภาษาโปรแกรมใหม่ทั้งหมดเข้าสู่ระบบสคริปต์ของบิตคอยน์ โดยขึ้นอยู่กับตัวดำเนินการ 9 ตัวที่รู้จักกันเป็น combiners

ในทางปฏิบัติความเรียบง่ายนั้นง่ายเกินไปและไม่ง่ายเลย คอมบิเนเตอร์ดั้งเดิมอยู่ในระดับต่ําอย่างน่าขันจนการดําเนินการขั้นพื้นฐานเช่นการเพิ่มเติมต้องดําเนินการอย่างลําบากตั้งแต่เริ่มต้น ความเรียบง่ายดิบจะเป็น verbose พิเศษในทางปฏิบัติ ดังนั้นการใช้งานจริงของ Simplicity จะใช้ประโยชน์จากระบบการแทนที่รหัสคล้ายกับการเรียกฟังก์ชันห้องสมุดที่เรียกว่า เจ็ท. ปัญหาทางปฏิบัติ / การเมืองนี้เกิดขึ้น: การตัดสินใจเกี่ยวกับเจ็ทที่จะนำมาใช้จะทำอย่างไร? ส่วนใหญ่เจ็ทจะถูกนำมาใช้ใน C++ เช่นเดียวกับโอปโค้ดอื่น ๆ ซึ่งจะต้องใช้ฟอร์กอ่อนสำหรับแต่ละเจ็ทใหม่

OP_FancyTreeManipulationStuff

มีหลากหลายรหัสโอปโค้ดที่เชี่ยวชาญเพียงในบางรายการที่มีการเสนอเพื่อดำเนินการต้นไม้ในลักษณะที่ประหยัดพื้นที่สำหรับข้อเสนอ L2 ที่ขึ้นอยู่กับพันธสัญญา ตัวอย่างเช่น Coinpools ได้เสนอทั้งTAPLEAF_UPDATE_VERIFYและOP_MERKLESUBซึ่งทั้งสองอย่างนี้จัดการต้นไม้ taproot ในรูปแบบที่จําเป็นสําหรับข้อเสนอ Coinpools และ แมตproposal ได้เสนอ opcode OP_CheckContractVerify ซึ่งโดยพื้นฐานคือการยืนยันคำแถลงเกี่ยวกับต้นไม้เมอร์เคิล

เพื่อวัตถุประสงค์ของบทความนี้เราไม่จำเป็นต้องอธิบายรายละเอียดของแต่ละข้อเสนอ แทนนั้นเราสามารถพูดถึงเป็นกลุ่มได้ว่าพวกเขาเป็นข้อเสนอที่เฉพาะเจาะจงที่ทำให้ L2 หนึ่งชั้นเป็นไปได้โดยไม่มีผลข้างเคียงที่ไม่ต้องการ พวกเขามีข้อดีของความมีประสิทธิภาพ: พวกเขาใช้พื้นที่บล็อกน้อยกว่าการบรรทุกเป้าหมายเดียวกันด้วยโอปโค้ดที่สามารถใช้กับทุกอย่าง เช่นการจัดการ OP_CAT แต่พวกเขายังมีข้อเสียของความซับซ้อนที่เพิ่มขึ้นต่อระบบสคริปต์ สำหรับการใช้งานที่อาจเป็นสายตาหรือการใช้งานที่จำเป็น

หาก Bitcoin นำระบบสคริปต์ Simplicity มาใช้งานจะเกิดการเคลื่อนไหวที่เหมือนกัน สิ่งที่เทียบเท่ากับ opcodes ใน Simplicity คือการเพิ่มเครื่องรีดสำหรับแบบแพทเทิร์นที่ใช้บ่อย อีกครั้งการนำเครื่องรีดมาใช้สำหรับการดำเนินการที่เฉพาะเจาะจงเช่นการจัดการต้นไม้ มีความเหมือนหรือไม่เหมือนกับการนำ opcodes ที่ซับซ้อนมาใช้สำหรับการดำเนินการที่เฉพาะเจาะจง

กองทุน

ระบบ L2 ทั้งหมดที่พยายามให้ผู้ใช้หลายคนแบ่งปัน UTXO เดียวกันสามารถถือว่าเป็นสระเงินทุกข์มหาศาลของผู้ใช้หลายคน โดยผู้ใช้จะมีสิทธิ์ถอนเงินอย่างใดอย่างหนึ่ง อาจมีกลไกเพิ่มเงินในสระเงินจะมากเกินไป (นอกเหนือจากการสร้างสระเงินด้วยเงินที่ได้รับมอบหมายล่วงหน้า)

เพื่อให้กลุ่มกองทุนมีประโยชน์จะต้องมี "สถานะข้อมูลการแบ่งปันข้อมูล" ที่เกี่ยวข้อง: มูลค่า txout ถูกแยกออกอย่างไร? หากกลุ่มกองทุนมีการพัฒนาเมื่อเวลาผ่านไปสถานะนั้นจะต้องเปลี่ยนแปลงเมื่อมีการเพิ่มหรือลบเงินออกจากกลุ่ม เนื่องจากเรากําลังสร้าง Bitcoin การเพิ่มหรือลบเงินออกจากพูลจะเกี่ยวข้องกับการใช้ UTXO ในการควบคุมพูลอย่างหลีกเลี่ยงไม่ได้

โปรดจำไว้ว่าระบบความเห็นร่วมของบิตคอยน์เอง จะมีพื้นฐานบนการตรวจสอบการเปลี่ยนแปลงของสถานะ: ธุรกรรมพิสูจน์ผ่านพยานของพวกเขาว่าการเปลี่ยนแปลงของสถานะของชุด UTXO ถูกต้อง; หลักการทำงานพิสูจน์ให้เรามาถึงข้อตกลงเกี่ยวกับชุดของธุรกรรมที่ถูกต้อง นี่หมายความว่ากองทุนก็คือการตรวจสอบการเปลี่ยนแปลงของสถานะตนเอง: เรากำลังพิสูจน์ถึงทุกๆ โหนดบิตคอยน์ว่ากฎของกองทุนถูกตามอยู่ในทุกการเปลี่ยนแปลงของสถานะ

แต่มีอีกแง่มุมที่สําคัญสําหรับกลุ่มกองทุน L2 ที่ไม่น่าเชื่อถือ: เมื่อสถานะของกลุ่มกองทุนเปลี่ยนไประบบจะต้องเผยแพร่ข้อมูลที่เพียงพอสําหรับผู้ใช้ที่เข้าร่วมในกลุ่มกองทุนเพื่อกู้คืนเงินทุนของพวกเขา หากเรายังไม่ได้ทําเช่นนั้นระบบของเราก็ไม่สามารถให้การถอนตัวฝ่ายเดียวโดยไม่ได้รับความร่วมมือจากบุคคลที่สาม แผนการที่ใช้ค่าสะสมจํานวนมากล้มเหลวที่นี่: พวกเขาประสบกับความล้มเหลวในความพร้อมใช้งานของข้อมูลซึ่งผู้ใช้ไม่สามารถกู้คืนเงินได้หากผู้ประสานงานบุคคลที่สามออฟไลน์เพราะพวกเขาไม่มีทางได้รับข้อมูลที่จําเป็นสําหรับพวกเขาในการสร้างธุรกรรมการกู้คืนกองทุนที่ถูกต้อง

เมื่อคํานึงถึงข้อ จํากัด เหล่านี้โครงสร้างข้อมูลใดที่กลุ่มกองทุนจะยึดตาม? อย่างหลีกเลี่ยงไม่ได้พวกเขาทั้งหมดเป็นต้นไม้บางชนิด โดยเฉพาะต้นไม้เมอร์เคิลบางชนิด พวกเขาจะต้องเป็นต้นไม้เพราะนั่นเป็นโครงสร้างข้อมูลที่ปรับขนาดได้เพียงแห่งเดียวในวิทยาการคอมพิวเตอร์ พวกเขาจะต้องถูกแมร์เคิลเพราะนั่นเป็นวิธีเดียวที่สมเหตุสมผลในการเข้ารหัสเพื่อผูกมัดกับสถานะของต้นไม้ ในที่สุดการอัปเดตต้นไม้จะถูกเผยแพร่ไปยัง Bitcoin blockchain อย่างหลีกเลี่ยงไม่ได้เพราะนั่นคือสิ่งที่ สื่อการเผยแพร่ผู้ใช้ L2 ทุกคนแบ่งปัน และเป็นเพียงอันเดียวที่เราสามารถบังคับผู้ใช้ให้เผยแพร่เพื่อย้ายเหรียญ และเนื่องจากการนำส่วนปฏิบัติของพันธบัตรไปใช้จะต้องใช้ส่วนของต้นไม้เพื่อตรวจสอบว่ากฎของพันธบัตรถูกปฏิบัติ

ดังนั้น หาก理论เน้นที่สูงถูกต้องออกไป วิธีการนี้จะแปลงเป็นสคริปต์และธุรกรรมบิตคอยน์ได้อย่างไรจริง ๆ

ธุรกรรมที่ลงลายมือแบบแยกตัวเอง

กรณีความเสื่อมของต้นไม้ที่มีใบเดียวอยู่ในนั้น ที่นี่สถานะของกลุ่มกองทุนของเราสามารถเปลี่ยนสถานะพูดคร่าวๆได้ครั้งเดียว ตัวอย่างเช่นช่อง Lightning มาตรฐานอยู่ในหมวดหมู่นี้และเมื่อเปิดแล้วจะสามารถปิดได้เท่านั้น ข้อมูลที่เผยแพร่เมื่อปิดช่องทางคือตัวธุรกรรมซึ่งเป็นข้อมูลที่เพียงพอสําหรับคู่สัญญาในช่องทางเพื่อเรียนรู้ txid จากข้อมูลบล็อกเชนและกู้คืนเงินของพวกเขาโดยการใช้จ่าย

"พันธสัญญา" เพียงอย่างเดียวที่จําเป็นในที่นี้คือพันธสัญญาพื้นฐานที่สุด: ธุรกรรมที่ลงนามล่วงหน้า

Txout Trees

รูปแบบการออกแบบที่ซับซ้อนและซับซ้อนกว่าที่เราเห็นในกลุ่มกองทุนคือต้นไม้ txout Ark เป็นตัวอย่างที่โดดเด่น ที่นี่กลุ่มกองทุนสามารถแบ่งได้โดยการใช้ UTXO รากในต้นไม้ของธุรกรรมที่กําหนดไว้ล่วงหน้าบังคับใช้กับพันธสัญญาง่ายๆเช่นธุรกรรมที่ลงนามล่วงหน้าหรือ CTV แบ่งมูลค่าของ UTXO นั้นออกเป็นจํานวนที่น้อยลงและน้อยลงจนกว่าจะถึงโหนดใบที่เจ้าของที่ถูกต้องใช้จ่ายได้

สิ่งสําคัญคือต้องตระหนักว่าจุดประสงค์ของต้นไม้ txout คือการให้ทางเลือกแก่ผู้ใช้เกี่ยวกับวิธีการกู้คืนเงินทุนของพวกเขาและตัวเลือกเหล่านั้นมีค่าใช้จ่าย: ต้นไม้ txout จะเป็นวิธีที่มีราคาแพงกว่าในการแยกกลุ่มเงินทุนส่งคืนให้กับเจ้าของมากกว่าการแยก UTXO ในการทําธุรกรรมเดียว แต่ละเลเยอร์ในทรีจะเพิ่มต้นทุนเนื่องจากไบต์ที่ใช้ใน txouts และ txins ที่จําเป็นในการสร้างเลเยอร์นั้น

ดังนั้นต้นไม้ txout สามารถให้ตัวเลือกประเภทใดบ้าง? อีกครั้ง Ark เป็นตัวอย่างที่ดี: เราไม่ต้องการให้การแลกเงินชนิดเดียวของ V-UTXO บนเชื่อมโยงต้องการให้ V-UTXO ทั้งหมดถูกนำเสนอบนเชื่อมโยง โดยใช้ต้นไม้ การแลกเงินสามารถแบ่งชิ้นเล็กๆ ของต้นไม้ได้จนกว่า V-UTXO ที่ต้องการจะถูกนำเสนอบนเชื่อมโยง

คล้ายกับกรณีธุรกรรมที่ได้รับลายเซ็นเอกสารแต่ละรายการ ข้อมูลที่เผยแพร่คือการธุรกรรมเอง ซึ่งจะแจ้งให้กระเป๋าเงินของผู้ใช้คนอื่น ๆ รู้ว่าจะใช้เงินของตนเองอย่างไรถ้าจำเป็น

ความสามารถในการขยายมาตรฐานของต้นไม้ txout มีประโยชน์ที่น่าสนใจ ค่าใช้จ่ายสำหรับ V-UTXO ตัวแรกที่ถูกนำเข้าบัญชีในสระเงินกับ n V-UTXOs ใช้เวลาประมาณ log2(n)log2⁡(n) ครั้งมากกว่าการทำธุรกรรมเดี่ยวเพราะต้องนำการทำธุรกรรมที่แยกแยะออกไปที่ chain อย่างน้อย log2(n) ระดับ อย่างไรก็ตาม เมื่อ V-UTXO ตัวแรกถูกนำเข้าบัญชีแล้ว V-UTXOs ที่เหลือจะถูกลดราคาเมื่อต้องการใช้บัญชีเงินเป็นวงเงินเพราะมีคนอื่นได้จ่ายค่าใช้จ่ายในการขุดการทำธุรกรรมระหว่าง

โปรดจำไว้ว่าจำนวนทั้งหมดขององค์ประกอบในต้นไม้ทวิภาคสอง

ใบปลิวคือ 2n นั่นหมายความว่าเพื่อให้ได้วาง V-UTXOs ทั้งหมดบนเครือข่าย ค่าใช้จ่ายรวมที่จะทำเช่นนั้นผ่านต้นไม้ txout จะเป็นคูณของค่าใช้จ่ายรวมที่จะทำเช่นนั้นในธุรกรรมเดียว มีประสิทธิภาพอย่างน่าแปลกใจ!

หรือบางทีไม่ใช่ ... หากขนาดรวมของการไถ่ถอนสระว่ายน้ำสูงเพียงพอ ก็อาจแสดงถึงความต้องการที่ไม่เล็กน้อยใน blockspace รวมทั้งหมด Blockspace เป็นระบบของการ供และความต้องการดังนั้นในบางจุดค่าธรรมเนียมจะเพิ่มขึ้นเนื่องจากความต้องการสูง สูงสุดก็เป็นไปได้ว่าจะสร้างต้นไม้ txout ใหญ่และลึกไปจนถึงจุดที่จะไถ่ถอนทุกอย่างจริงๆ

V-UTXO ในต้นไม้นั้นเป็นไปไม่ได้

คำถามที่ยังเปิดอยู่เกี่ยวกับต้นไม้ txout คือใครจะจ่ายค่าธรรมเนียมและวิธีใดบ้าง? วิธีหนึ่งที่ชัดเจนคือการใช้ keyless anchor outputs บนธุรกรรมใบไม้และอนุญาตให้ผู้ใดก็ตามที่ต้องการให้ธุรกรรมใบไม้ถูกขุดเพื่อชำระค่าธรรมเนียมผ่าน CPFP ในบางกรณีใน V-UTXOs เองสามารถใช้จ่ายได้ทันทีหลังจากสร้างโดยไม่ต้องมีความล่าช้า CSV ดังนั้น V-UTXOs เองสามารถใช้ในการเพิ่มค่าธรรมเนียมผ่าน CPFP ได้

RBF มีความซับซ้อนในการดําเนินการเนื่องจากการอนุญาต: สถานที่ที่ชัดเจนในการรับค่าธรรมเนียมสําหรับ RBF คือค่า V-UTXO แต่คุณจะมั่นใจได้อย่างไรว่ามีเพียงเจ้าของเท่านั้นที่สามารถลงนามในธุรกรรมค่าธรรมเนียมที่สูงขึ้นได้? ในหลาย ๆ สถานการณ์ไม่ชัดเจนว่าจะทําอย่างไรในลักษณะที่มีประสิทธิภาพมากกว่าเอาต์พุตสมอแบบไม่ใช้กุญแจ อย่างไรก็ตามการไม่ทําเช่นนั้นถือเป็นความท้าทายที่ร้ายแรงสําหรับแผนการที่ใช้โดยกระเป๋าเงินของผู้ใช้ปลายทางซึ่งอาจไม่มี UTXO เพื่อใช้จ่ายเพื่อดําเนินการ CPFP หาก V-UTXOs เองไม่สามารถใช้ได้ทันที

สุดท้ายต้องคิดให้รอบคอบว่ามีสิ่งจูงใจอะไรบ้างในระบบต้นไม้โดยคํานึงถึงการชําระค่าธรรมเนียม ตัวอย่างเช่นในระบบ Ark like หากชุดของ V-UTXOs มีค่าใช้จ่ายมากเกินไปที่จะคุ้มค่ากับการใช้ V-UTXOs แบบ on-chain ผู้ประสานงานที่ไม่ร่วมมือกันอาจปฏิเสธที่จะอนุญาตให้ V-UTXOs เหล่านั้นถูกแลกนอกห่วงโซ่แล้วทํากําไรโดยการขโมยมูลค่าของ V-UTXOs เหล่านั้นในการใช้จ่าย UTXO เพียงครั้งเดียวเมื่อหมดเวลา

ถ้าเป็นกรณีนี้ อาจจะสามารถวิเคราะห์ได้ว่าระบบเช่นนี้จะไม่ผ่านเกณฑ์ของเราที่จะเป็น L2 สำหรับ V-UTXO ขนาดเล็ก

Balance Based Schemes

เครื่องสถานะของต้นไม้ txout ยังคงค่อนข้างง่าย: มีกลุ่มกองทุนอยู่หรือถูกใช้เพื่อสร้างกลุ่มกองทุนขนาดเล็กสองกลุ่มขึ้นไป ด้วยพันธสัญญาขั้นสูงเราสามารถปฏิบัติต่อกลุ่มกองทุนเป็นยอดคงเหลือที่กําลังพัฒนาโดยมีความสามารถในการเพิ่มและลบเงินทุนออกจากยอดคงเหลือนั้น

ในการทําเช่นนี้เราจําเป็นต้องใช้เครื่องของรัฐที่ไม่สําคัญ แต่เรายังต้องการสิ่งที่เป็นฐานข้อมูลที่ใช้ร่วมกันเป็นหลัก ทําไม เพราะเป้าหมายที่นี่คือการแบ่งปัน UTXO หนึ่งรายการกับเจ้าของที่แตกต่างกันมากมาย สุดท้ายหากเราจะได้รับการปรับปรุงความสามารถในการปรับขนาดได้จริงเราต้องทําเช่นนั้นในลักษณะที่ทําให้ข้อมูลความเป็นเจ้าของนั้นน้อยที่สุด

ข้อกำหนดเหล่านี้ส่งผลให้เราต้องมีโครงสร้างข้อมูลแบบต้นไม้ที่มีลักษณะเช่นเดียวกับต้นไม้ผลรวมเมอร์เคิล การจัดการโครงสร้างข้อมูลดังกล่าวจำเป็นต้องใช้คำสั่ง OP_CAT หรือคำสั่งการตรวจสอบภาพรวมที่เป็นศูนย์องค์ความรู้หรือคำสั่งการจัดการต้นไม้ที่เฉพาะเจาะจง

ที่น่าสนใจเช่นเดียวกับในต้นไม้ txout คุณไม่สามารถทําได้ดีไปกว่าการปรับขนาด order log(n) ในขณะที่รักษาคุณสมบัติความปลอดภัยที่คล้ายกัน ทําไม สมมติว่าเรามีสมมุติฐาน OP_ZKP ซึ่งผ่านคณิตศาสตร์ขั้นสูงบางอย่างต้องการเพียง 32 ไบต์เพื่อพิสูจน์คําสั่งใด ๆ ในขณะที่หลักฐาน zk นี้สามารถพิสูจน์ได้ว่าโครงสร้างข้อมูล merkelized ได้รับการจัดการตามกฎของระบบเลเยอร์ 2 แต่ก็ไม่สามารถให้ข้อมูลที่จําเป็นสําหรับผู้ใช้รายต่อไปเพื่อทําการเปลี่ยนแปลงสถานะได้ สิ่งนี้ไม่ผ่านเกณฑ์ที่เราต้องการในการเปิดใช้งานการถอนโดยไม่มีเงื่อนไข: ที่ดีที่สุดผู้ใช้รายหนึ่งอาจสามารถถอนเงินโดยไม่มีเงื่อนไขได้ แต่ไม่มีผู้ใช้เพิ่มเติมสามารถทําได้

ในทวีปเอเชีย ถ้าส่วนที่ปรับแก้ของโครงสร้างข้อมูล merklized ถูกเผยแพร่ผ่าน covenant scriptsig - เช่น sibling digests ในต้นไม้เมอร์เคิล - ผู้ใช้ถัดไปจะมีข้อมูลเพียงพอที่จะอัพเดตความเข้าใจของสถานะระบบและทำการถอนออกได้โดยไม่มีเงื่อนไข

วิธีที่เป็นไปได้ในการแก้ปัญหานี้คือหากสัญญากำหนดให้มีการพิสูจน์การเผยแพร่บนสื่อพิมพ์ที่แตกต่างจากโซ่ Bitcoin อย่างไรก็ตาม การค้ำประกันความปลอดภัยจะอ่อนแอกว่าที่เป็นไปได้ผ่าน Bitcoin

สุดท้ายแล้ว สังเกตว่าต้นไม้ txout และวิธีการที่พึ่งพากันได้รับการรวมกัน หากโครงสร้างข้อมูลที่กำลังถูกจัดการเป็นต้นไม้ txout เงินทุนสามารถเพิ่มเข้าไปในต้นไม้ txout โดยใช้เงินที่ได้รับและเพิ่มเงินทุนใหม่ ด้วยสคริปต์สัญญาที่ตรวจสอบว่าเงินทุนจริงๆ ถูกเพิ่มในต้นไม้ txout อย่างเช่นเดียวกับนั้น สามารถลบเงินทุนได้ด้วยกลไกทั้งหมดที่มีอยู่ปกติสำหรับต้นไม้ txout Advanced Ark เป็นตัวอย่างของคลาสนี้

อัตราส่วนข้อมูลที่ล้มเหลว

L2 ประสบความสำเร็จในการขยายมิติโดยการเพิ่มความต้องการในการปฏิสัมพันธ์ในสถานการณ์ที่เป็นศัตรู ในกรณีส่วนใหญ่นั้นหมายความว่าฝ่ายซื่อสัตย์ในโปรโตคอลต้องมีเวลาที่ต้องทำการทำธุรกรรมให้เหมือนถูกขุด; หากไม่ทำตามเวลาที่กำหนด ก็มีโอกาสถูกขโมยเงิน

ความจุบล็อกสูงสุดในบล็อกเชนทุกประเภท (และบล็อกเชนที่จัดการ) ถูกจำกัดโดยข้อจำกัดทางเทคนิค ในบิตคอยน์ ขนาดบล็อกสูงสุดคือตัวที่บิตคอยน์ทำงานเกือบแบบเต็มที่ โดยตลอดเวลา โดยเนื่องจากการขุดบิตคอยน์ทำหน้าที่เป็นระบบการประมูล โดยขายพื้นที่บล็อกให้กับผู้เสนอราคาสูงสุด ในการปฏิบัติภาคนี้ นั่นหมายความว่าค่าธรรมเนียมขั้นต่ำในการทำธุรกรรมเพื่อให้ทำการขุดขึ้นและลดลงตามความต้องการ

อัตราค่าธรรมเนียมเป็นปัจจัยสำคัญในเศรษฐศาสตร์ L2 และโหมดความล้มเหลว ตัวอย่างเช่นใน Lightning HTLC ขนาดเล็กเหลือเกินที่จะถูกแลกเปลี่ยนอย่างกำไรได้ใช้โมเดลความปลอดภัยที่แตกต่างจาก HTLC ขนาดใหญ่กว่า ในขณะที่โปรโตคอล Lightning ยังไม่ได้นำมาใช้จริงแต่ในทฤษฎีค่านี้ควรเป็นแบบไดนามิก ขึ้นอยู่กับอัตราค่าธรรมเนียมที่เพิ่มขึ้นและลดลง โดยต้องการให้เป็นไปตามจุดที่แตกต่างกันไป จนกระทั่งฝ่ายใดฝ่ายหนึ่งสามารถเลือกว่าจะมีหรือไม่มี HTLC ในธุรกรรมที่ได้รับการยืนยันในการตั้งฝากในอัตราค่าธรรมเนียมใดๆ

มีการพิจารณาหลายวิธีการโจมตีที่เสนอขึ้นเมื่อสถานการณ์นี้เกิดขึ้นโดยเจตนาบนเทคโนโลยี Lightning เช่น การทำให้ระบบเติมเงินเกิดภาวะติดขัดและการขโมย²²และการโจมตีการออกจากกลุ่มมวล²³. โดยเนื่องจากความจุของบล็อกเชน Bitcoin ถูกแบ่งปันในทุกๆ กรณีการใช้งาน การโจมตีระหว่างระบบ L2 ที่แตกต่างกันก็เป็นไปได้: เช่น การเรียกใช้การออกจาก Ark อย่างมวลกระแสเพื่อหารายได้จากช่องทาง Lightning

L2 ที่แบ่งปัน UTXO ในหมู่ผู้ใช้หลายคนโดยเนื้อแท้ทําให้ปัญหาเหล่านี้อาจแย่ลงเนื่องจากความต้องการพื้นที่บล็อกกรณีที่เลวร้ายที่สุดในระหว่างความล้มเหลวนั้นสูงขึ้นตามสัดส่วน ในขณะที่เขียนเราไม่เคยเห็นความล้มเหลวขนาดใหญ่ใน Lightning ที่ต้องปิดช่องจํานวนมากในคราวเดียว มีข้อโต้แย้งที่ดีว่าเราควรได้รับประสบการณ์การดําเนินงานเพิ่มเติมกับ Lightning และการปรับขนาดประมาณ 1-UTXO-ต่อผู้ใช้ก่อนที่จะผลักดันขีด จํากัด ให้ไกลยิ่งขึ้นด้วยรูปแบบการแบ่งปัน UTXO

ประการที่สองก่อนที่รูปแบบการแบ่งปัน UTXO ใหม่จะถูกนํามาใช้อย่างกว้างขวางควรทําการวิจัยอย่างรอบคอบเกี่ยวกับความสามารถในการทํากําไรที่อาจเกิดขึ้นจากการโจมตีในช่วงที่มีความต้องการบล็อกสเปซสูง ตัวอย่างเช่นในระบบเช่น Ark ที่ ASP สามารถไถ่ถอนเงินโดยใช้ blockspace น้อยกว่าฝ่ายอื่น ๆ อาจเป็นกรณีที่จงใจทําให้เกิดอัตราค่าธรรมเนียมสูงแล้วยึดเงินที่ไม่สามารถถอนออกได้เพียงฝ่ายเดียวเป็นการฉ้อโกงที่ทํากําไรได้ละเมิดเงื่อนไขของเราทั้งสองสําหรับระบบ L2 ที่แท้จริง

การล้างข้อมูลฉันทามติ

มีหลายสิ่งที่ Satoshi ผิดพลาดในโปรโตคอล Bitcoin เริ่มต้นโดยเฉพาะอย่างยิ่งการเขียนสคริปต์การโจมตี DoS การโจมตี timewarp และปัญหาเกี่ยวกับต้นไม้เมอร์เคิล ก่อนหน้านี้ข้อบกพร่องฉันทามติอื่น ๆ จํานวนหนึ่งได้รับการแก้ไขแล้วด้วย soft-forks เช่นการเปลี่ยนไปใช้การประเมิน nLockTime ตามเวลาเทียบกับเวลามัธยฐานที่ผ่านมา (พยายาม) แก้ไขปัญหา txid ที่ซ้ํากันเป็นต้น

ฟอร์กซอฟต์ล่าสุดที่แยกต่างหาก ฟอร์กซอฟต์แบบ taproot มีกระบวนการใช้งานที่ท้าทายกันอย่างมาก ใช้เวลานานในการใช้งานจริง ข้อเสนอสำหรับการทำฟอร์กซอฟต์ล้างความไม่เออเร่อก่อนที่จะเปิดใช้งานออปคอดใหม่หรือคุณสมบัติอื่น ๆ สำหรับ L2 ประเภทใหม่ คือเราจะได้เรียนรู้ว่าชุมชนที่กว้างขวางเสียใจกับการปฏิบัติตามที่ควรจะเป็นฟอร์กซอฟต์ที่ไม่เกี่ยวข้องอย่างสิ้นเชิงที่มีประโยชน์สำหรับทุกคนได้อย่างไร

ทดสอบซอฟต์ฟอร์กที่ขึ้นอยู่กับ L2

นักพัฒนาไม่จําเป็นต้องรอให้ซอฟต์ส้อมเกิดขึ้นจริงเพื่อทดสอบความคิดของพวกเขา หนึ่งในวิธีการที่ซับซ้อนโดยเฉพาะอย่างยิ่งถูกใช้โดยนักพัฒนา Ark ใน อาร์คโดยไม่มีการทำสัญญา คือการจําลองพันธสัญญาที่พวกเขาต้องการด้วยธุรกรรมที่ลงนามล่วงหน้า สิ่งนี้ช่วยให้พวกเขาทดสอบความคิดของ Ark ด้วย BTC จริงบน mainnet ที่มีลักษณะความไว้วางใจเช่นเดียวกับที่ Ark คาดว่าจะบรรลุด้วยพันธสัญญา การแลกเปลี่ยนคือ Ark ที่ไม่มีพันธสัญญากําหนดให้ทุกฝ่ายต้องออนไลน์เพื่อลงนามในธุรกรรมที่ลงนามล่วงหน้า เนื่องจาก clArk ทํางานร่วมกับ BTC จริงจึงอาจพิสูจน์ได้ว่ามีประโยชน์เพียงพอที่จะใช้ในการผลิตสําหรับการถ่ายโอนกรณีการใช้งานบางอย่างที่สามารถทนต่อการแลกเปลี่ยนการโต้ตอบได้

วิธีที่ง่ายกว่าคือการแสร้งทําเป็นว่าบางฝ่ายไม่สามารถทําสิ่งที่พันธสัญญาจะป้องกันได้ ตัวอย่างเช่น หากโปรโตคอลที่เสนอต้องการใช้ CTV เพื่อบังคับใช้ว่าต้นไม้ txout ถูกใช้ไปในแผนผังธุรกรรม การใช้ CTV แต่ละครั้งอาจถูกแทนที่ด้วย NOP หรือ CheckSig ในขณะที่ในความเป็นจริงต้นไม้ txout ไม่ได้ถูกบังคับใช้จริงทุกบิตของรหัสโต้ตอบกับต้นไม้และแต่ละฝ่ายสามารถทดสอบได้ราวกับว่ามันเป็นและเนื่องจาก NOP และ CheckSig ได้รับอนุญาตในสคริปต์มาตรฐานโปรโตคอลสามารถทดสอบบน mainnet ด้วยเงินจริง

ซอฟต์ส้อมที่มีศักยภาพ

เส้นทางข้างหน้าคืออะไร? ที่นี่เราจะทําแผนภูมิสคีม L2 หลักทั้งหมดที่เราได้วิเคราะห์และสิ่งที่ซอฟต์ส้อมมีประโยชน์ (U) หรือจําเป็น (R) เพื่อให้รูปแบบ L2 เหล่านี้ประสบความสําเร็จ ตามที่กล่าวไว้ข้างต้น OP_CAT (และโดยส่วนขยาย Script Revival ซึ่งรวมถึง OP_CAT) สามารถเลียนแบบซอฟต์ฟอร์กอื่น ๆ ทั้งหมดในรายการนี้ยกเว้น OP_Expire และ Fee Sponsorship - ดังนั้นในกรณีที่ความต้องการของโครงการได้รับการตอบสนองอย่างมีประสิทธิภาพมากที่สุดโดย soft-fork อื่น ๆ โดยตรงเราจะไม่รวม OP_CAT

นอกจากนี้เรายังจะทิ้ง opcodes การจัดการต้นไม้ merkle ที่เสนอทั้งหมด พวกเขาทั้งหมดมีความเฉพาะเจาะจงเกินไปเฉพาะกรณีการใช้งานมากเกินไปที่จะมีโอกาสสําคัญในการรับเลี้ยงบุตรบุญธรรมในเวลานี้ ในขอบเขตที่ opcodes เหล่านี้มีประโยชน์การใช้เอฟเฟกต์ของพวกเขาผ่าน OP_CAT และ / หรือ Script Revival เป็นเส้นทางที่มีแนวโน้มมากขึ้นในการนําไปใช้

CTV เป็นผู้ชนะที่ชัดเจนที่นี่ ตามด้วย SIGHASH_ANYPREVOUT (OP_Expire มีประโยชน์สำหรับหลายสิ่ง โดยการเป็นการแทนที่การแก้ไขรอบการปั่น แต่ไม่เป็นสิ่งที่สำคัญ) CTV ชนะเพราะมีสิ่งมากมายที่ตรงกับแบบแผนการออกแบบ 'ตรวจสอบให้แน่ใจว่าธุรกรรมการใช้จ่ายตรงกับเทมเพลตนี้' แม้แม้ว่าการสร้างสรรค์ OP_CAT ก็สามารถใช้ CTV อย่างมีประสิทธิภาพได้อย่างมีประสิทธิภาพ

ไม่เหมือนกับ OP_CAT CTV ไม่ควรเสี่ยงต่อผลกระทบที่ไม่ได้ตั้งใจ นอกจากกระตุ้นการชำระค่าธรรมเนียมนอกกรณีบางส่วน นั่นไม่ใช่สิ่งที่ดี แต่ยังไม่มีใครเสนอทางเลือกที่ได้รับการสนับสนุนอย่างแพร่หลาย

ข้อเสนอส่วนตัวของฉัน: ทำการล้างความเห็นร่วมกันด้วยซอฟต์ฟอร์กชนิดนุ่ม ตามด้วย CTV

ปฏิเสธ:

1. บทความนี้พิมพ์ซ้ําจาก [petertodd], ส่งต่อชื่อเรื่องเดิม 'Is the Ethereum Roadmap Off Track?' ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [petertodd] หากมีข้อเสนอแนะในการเผยแพร่นี้ กรุณาติดต่อ เรียนรู้เกตทีมงานและพวกเขาจะดำเนินการด้วยความรวดเร็ว

2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงเจ้าของเท่านั้น และไม่เป็นการให้คำแนะนำเกี่ยวกับการลงทุนใด ๆ

3. การแปลบทความเป็นภาษาอื่น ๆ ทำโดยทีม Gate Learn หากไม่ระบุไว้ การคัดลอก การกระจาย หรือการเอาเอกสารที่แปลมาลอกมาจากผู้แปลนั้นถือเป็นการละเมิดลิขสิทธิ์