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

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

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

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

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

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

THE GREAT SCRIPT RESTORATION

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

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

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

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

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

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

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

OPCODES

• OP_CAT: นําข้อมูลสองชิ้นบนสแต็คและเพิ่มเข้าด้วยกันเพื่อสร้างข้อมูล
• OP_SUBSTR: ใช้อาร์กิวเมนต์ความยาวเป็นไบต์และคว้าชิ้นส่วนของข้อมูลออกจากสแต็กโดยลบไบต์จํานวนมากออกจากมันและนํากลับมา
• OP_LEFT & OP_RIGHT: ใช้อาร์กิวเมนต์ความยาวและลบไบต์จํานวนมากออกจากด้านหนึ่งหรืออีกด้านหนึ่งของข้อมูลบนสแต็ก
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: ใช้องค์ประกอบข้อมูลจากสแต็กและดําเนินการ bit ที่เกี่ยวข้อง
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: ตัวดําเนินการทางคณิตศาสตร์สําหรับการคูณ การหาร และการดําเนินการโมดูโล (ส่งกลับส่วนที่เหลือของการหาร)

สิ่งที่กล่าวมาข้างต้นเป็น opcodes ที่ตั้งใจจะเรียกคืน นอกจากนี้ Rusty ยังเสนออีกสามอย่างเพื่อลดความซับซ้อนขององค์ประกอบของ opcodes ที่แตกต่างกัน

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

ทําไมเราถึงต้องการทําสิ่งนี้

Layer 2s เป็นส่วนขยายของเลเยอร์พื้นฐานของ Bitcoin โดยเนื้อแท้แล้วพวกเขาถูก จํากัด โดยธรรมชาติในแง่ของฟังก์ชันการทํางานโดยการทํางานของเลเยอร์พื้นฐาน ฟ้าผ่าต้องใช้ซอฟต์ฟอร์กแยกกันสามตัว CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) และ Segregated Witness ก่อนที่จะสามารถนําไปใช้ได้จริง

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

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

ในมุมมองที่สูงนี่คือประเภทของฟังก์ชันที่เราต้องการ:

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

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

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

HOW TO MAKE THIS SAFE: VAROPS

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

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

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

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

สิ่งนี้จะแก้ปัญหาความเสี่ยงในการปฏิเสธการให้บริการที่ทําให้ Satoshi ปิดการใช้งาน opcodes เหล่านี้ทั้งหมดตั้งแต่แรก

FORWARD MOMENTUM

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

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

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

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

ข้อจํากัดความรับผิดชอบ:

1. บทความนี้พิมพ์ซ้ําจาก [bitcoinmagazine] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [SHINOBI] หากมีการคัดค้านการพิมพ์ซ้ํานี้ โปรดติดต่อทีม Gate Learn และพวกเขาจะจัดการทันที
2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปล