ผู้เขียนต้นฉบับ: ชิโนบิ

การรวบรวมต้นฉบับ: บล็อกยูนิคอร์น

แม้จะมีขอบเขตข้อเสนอที่ค่อนข้างกว้าง แต่อะไรคือเหตุผลว่าทำไม “การกู้คืนสคริปต์ที่ยอดเยี่ยม” ของ Rusty Russell อาจเป็นหนทางสู่การพัฒนา Bitcoin

บล็อกยูนิคอร์น หมายเหตุ: Rusty Russell เป็นนักพัฒนาที่กระตือรือร้นในชุมชน Bitcoin และเป็นที่เคารพนับถืออย่างมากในชุมชน เขาทำงานที่โดดเด่นในการพัฒนาเคอร์เนล Linux และยังมีส่วนร่วมในโครงการพัฒนา Bitcoin Core มากมาย

เดิมที Bitcoin ได้รับการออกแบบด้วยภาษาสคริปต์ที่สมบูรณ์ซึ่งออกแบบมาเพื่อครอบคลุมและสนับสนุนกรณีการใช้งานด้านความปลอดภัยที่อาจเกิดขึ้นที่ผู้ใช้อาจเกิดขึ้นในอนาคต ดังที่ Satoshi Nakamoto พูดก่อนที่จะหายตัวไป:

“ธรรมชาติของ Bitcoin คือเมื่อเวอร์ชัน 0.1 เปิดตัว การออกแบบหลักจะถูกตั้งค่าไว้ตลอดวงจรชีวิตที่เหลือ ดังนั้นฉันจึงต้องการออกแบบเพื่อรองรับธุรกรรมทุกประเภทที่เป็นไปได้ที่ฉันนึกได้ ปัญหาคือ ทุกอย่างมีรหัสสนับสนุนพิเศษ และฟิลด์ข้อมูลเป็นสิ่งจำเป็น ซึ่งส่งผลให้เกิดกรณีพิเศษมากมายไม่ว่าจะถูกใช้หรือไม่ก็ตาม วิธีแก้ไขคือการเขียนสคริปต์ ซึ่งสรุปปัญหาเพื่อให้ทั้งสองฝ่ายสามารถใช้เงื่อนไขเฉพาะเพื่ออธิบายธุรกรรมของตนไปยังเครือข่ายโหนดได้ ประเมินหรือตรวจสอบตามเงื่อนไขเหล่านี้" - Satoshi Nakamoto, 17 มิถุนายน 2010

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

ก่อนที่เขาจะหายตัวไป Satoshi ได้ลบ opcodes เหล่านี้ 15 ตัวออก ปิดการใช้งานทั้งหมด และเพิ่มขีดจำกัดฮาร์ดสแต็กของ script engine ที่จำกัดขนาดของบล็อกข้อมูลที่สามารถดำเนินการได้ (520 ไบต์) นี่เป็นเพราะเขาทำผิดพลาดจริง ๆ โดยทิ้งหลายวิธีในการใช้สคริปต์ที่ซับซ้อนเพื่อโจมตี DOS บนเครือข่ายทั้งหมด (ส่งคำขอสแปมจำนวนมาก ทำให้เครือข่ายต้องหยุดชะงัก) สร้างธุรกรรมขนาดใหญ่และมีราคาแพง และจะทำให้โหนดขัดข้อง

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

ตั้งแต่นั้นมา การอัปเกรดเป็น Bitcoin ทุกครั้งได้ลงเอยด้วยการเพิ่มประสิทธิภาพการทำงานของฟังก์ชันการทำงานที่เหลืออยู่ แก้ไขข้อบกพร่องอื่นๆ ที่ร้ายแรงน้อยกว่าที่ Satoshi ทิ้งไว้ให้เรา และขยายฟังก์ชันการทำงานของชุดย่อยของสคริปต์ที่เหลือของเรา

สคริปต์ที่ยอดเยี่ยมสำหรับการกู้คืน

ในการประชุม Bitcoin++ ในออสตินเมื่อต้นเดือนพฤษภาคม Rusty Russell ผู้พัฒนาหลักของ Lightning Network ได้ทำข้อเสนอที่รุนแรงมากในการพูดคุยครั้งแรกในการประชุม โดยเขาได้เสนอให้เปิดใช้งาน Satoshi Nakamoto อีกครั้ง แนวคิดคือการปิดการใช้งาน opcodes ส่วนใหญ่ก่อนที่จะหายไปในปี 2010

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

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

ตัวอย่างเช่น ANYPREVOUT (APO) เป็นข้อเสนอที่อนุญาตให้ใช้ลายเซ็นซ้ำในธุรกรรมต่างๆ ตราบใดที่สคริปต์อินพุตและจำนวนเท่ากัน ข้อเสนอนี้ได้รับการออกแบบมาโดยเฉพาะเพื่อเพิ่มประสิทธิภาพ Lightning Network และเวอร์ชันหลายฝ่าย CHECKTEMPLATEVERIFY (CTV) เป็นข้อเสนอที่กำหนดให้ต้องใช้เหรียญในธุรกรรมที่ตรงกับธุรกรรมที่กำหนดไว้ล่วงหน้าทุกประการ ข้อเสนอนี้ออกแบบมาเพื่อขยายฟังก์ชันการทำงานของห่วงโซ่ธุรกรรมที่ลงนามล่วงหน้าโดยทำให้ไม่น่าเชื่อถือโดยสิ้นเชิง OP_VAULT ได้รับการออกแบบมาโดยเฉพาะเพื่อกำหนดระยะเวลา "หมดเวลา" สำหรับรูปแบบการจัดเก็บข้อมูลแบบเย็น เพื่อให้ผู้ใช้สามารถ "ยกเลิก" การแยกข้อมูลจากการจัดเก็บแบบเย็นโดยส่งไปยังการตั้งค่า multi-sig ที่เย็นกว่า เพื่อป้องกันไม่ให้คีย์ถูกบุกรุก

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

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

นี่คือตรรกะเบื้องหลัง "Great Script Recovery" ด้วยการผลักดันและวิเคราะห์การกู้คืนสคริปต์ทั้งหมดตามที่ Satoshi ออกแบบไว้ในตอนแรก เราสามารถลองสำรวจพื้นที่ฟีเจอร์ทั้งหมดที่เราต้องการได้ แทนที่จะโต้แย้งและโต้แย้งว่าส่วนขยายฟีเจอร์ขนาดเล็กใดดีพอในขณะนี้

OPCODES (รหัสการทำงาน)

• OP_CAT: รับข้อมูลสองรายการจากสแต็กและเพิ่มเป็นข้อมูลเดียว

• OP_SUBSTR: ยอมรับพารามิเตอร์ความยาว (เป็นไบต์) รับชิ้นส่วนข้อมูลจากสแต็ก ลบไบต์ที่มีความยาวนั้นออก และวางกลับลงบนสแต็ก

• OP_LEFT และ OP_RIGHT: ยอมรับพารามิเตอร์ความยาว รับชิ้นส่วนข้อมูลจากสแต็ก และลบไบต์ของความยาวที่ระบุออกจากด้านใดด้านหนึ่ง

• OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_UPSHIFT และ OP_DOWNSHIFT: ยอมรับองค์ประกอบข้อมูลและดำเนินการบิตที่สอดคล้องกันกับองค์ประกอบข้อมูล

• OP_ 2 MUL, OP_2D IV, OP_MUL, OP_DIV และ OP_MOD: ตัวดำเนินการทางคณิตศาสตร์สำหรับการคูณ การหาร และการดำเนินการแบบโมดูโล (ส่งคืนส่วนที่เหลือของการหาร)

นอกเหนือจาก opcodes ที่ระบุไว้ข้างต้นเพื่อการกู้คืนแล้ว Rusty Russell ยังเสนอ opcodes เพิ่มเติมอีกสามรายการที่ออกแบบมาเพื่อลดความซับซ้อนของการรวม opcodes ต่างๆ:

OP_CTV (หรือ TXHASH/opcode ที่เทียบเท่า): ช่วยให้สามารถบังคับใช้บางส่วนของธุรกรรมได้อย่างละเอียด โดยกำหนดให้ส่วนเหล่านั้นต้องสอดคล้องกับเนื้อหาที่กำหนดไว้ล่วงหน้าทุกประการ

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

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

ทำไมเราถึงทำเช่นนี้

เครือข่ายเลเยอร์ 2 เป็นส่วนเสริมของเลเยอร์ฐานของ Bitcoin และถูกจำกัดการใช้งานโดยความสามารถของเลเยอร์ฐาน Lightning Network ต้องใช้ soft fork สามตัวแยกกันก่อนจึงจะสามารถใช้งานได้จริง: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) และ Segregated Witness

คุณไม่สามารถสร้างเครือข่ายเลเยอร์ 2 ที่ยืดหยุ่นกว่านี้ได้หากไม่มีเลเยอร์ฐานที่ยืดหยุ่นกว่านี้ ทางลัดเดียวคือการเชื่อใจบุคคลที่สาม ซึ่งค่อนข้างง่ายและชัดเจน และฉันหวังว่าเราทุกคนปรารถนาที่จะลบความไว้วางใจจากบุคคลที่สามให้มากที่สุดเท่าที่จะเป็นไปได้จากทุกแง่มุมของการโต้ตอบกับ Bitcoin ในวงกว้าง

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

ในระดับสูง นี่คือฟังก์ชันที่เราต้องการ:

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

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

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

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

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

Taproot เปลี่ยนวิธีการทำงาน แทนที่จะใช้ขีดจำกัดบล็อกเดียวทั่วโลก แต่ละธุรกรรมจะมีขีดจำกัด sigops (การดำเนินการลายเซ็น) ของตัวเอง ซึ่งแปรผันตามขนาดของธุรกรรม โดยพื้นฐานแล้วจะมีขีดจำกัดทั่วโลกเท่ากัน แต่ช่วยให้เข้าใจได้ง่ายขึ้นว่ามี Sigops จำนวนเท่าใดต่อธุรกรรม

การเปลี่ยนแปลงของ Taproot ในการจัดการกับขีดจำกัด sigops (การดำเนินการลายเซ็น) ของแต่ละธุรกรรมจะเปิดโอกาสให้มีแนวทางทั่วไป ซึ่ง Rusty Russell แนะนำในขีดจำกัด varops แนวคิดก็คือการกำหนดต้นทุนให้กับ opcode ที่เปิดใช้งานใหม่แต่ละรายการโดยคำนึงถึงสถานการณ์กรณีที่เลวร้ายที่สุดที่ opcode แต่ละอันสามารถสร้างได้ กล่าวคือ ต้นทุนการคำนวณที่แพงที่สุดที่เกิดขึ้นเมื่อตรวจสอบความถูกต้อง ด้วยวิธีนี้ แต่ละ opcode จะมีขีดจำกัด "sigops" ของตัวเอง ซึ่งจำกัดปริมาณทรัพยากรที่สามารถใช้ได้ในระหว่างกระบวนการตรวจสอบ นอกจากนี้ยังจะขึ้นอยู่กับขนาดของธุรกรรมใดๆ ที่ใช้ opcode เหล่านี้ ดังนั้นจึงสามารถอนุมานได้ในขณะที่ยังคงเพิ่มขีดจำกัดโดยรวมต่อบล็อกโดยนัย

วิธีนี้จะแก้ไขการโจมตี DOS (ทำให้เครือข่ายล่มโดยการส่งคำขอสแปมจำนวนมาก) เนื่องจากธุรกรรมสแปมเหล่านี้ ซึ่งเป็นสาเหตุที่ทำให้ Satoshi ปิดการใช้งาน opcodes เหล่านี้ทั้งหมดตั้งแต่แรก

โมเมนตัมไปข้างหน้า

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

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

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

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