ทศวรรษหน้า ภาค 2: ถนนข้างหน้า

เราเริ่มเห็นเมล็ดพันธุกรรมของศักยภาพชั้นที่สองที่เริ่มเจริญจากพื้นฐานที่ได้รับการเพิ่มเติมหรือปรับปรุงในทศวรรย์แรก Lightning ในขณะที่ยังมีข้อจำกัดบางส่วนที่ใหญ่มาก กำลังเริ่มเจริญขึ้นแล้ว และนั้นเป็นเพียงเวอร์ชันแรกที่จำกัดที่กำหนดและใช้งานอยู่ในปัจจุบัน ตอนนี้มี sidechains ของชนิดต่าง ๆ ที่ใช้งาน: Liquid, RSK, และ ( โดย Commerceblock นี่เพียงเริ่มต้น

Schnorr และ Taproot

เพียงข้ามขอบฟ้าเรามีการรวมกันของ Schnorr และ Taproot ในด้าน Schnorr ของสิ่งต่าง ๆ นี่เป็นสิ่งที่ถูกกว่ามากในการตรวจสอบรูปแบบลายเซ็นในแบทช์รวมถึงการก้าวกระโดดครั้งใหญ่ครั้งต่อไปในการเพิ่มประสิทธิภาพการสร้างสคริปต์หลายลายเซ็นใน บิทคอยน์ Multisig เริ่มต้นจากการบรรจุคีย์สาธารณะและสคริปต์ทั้งหมดสําหรับ multisig ในเอาต์พุตธุรกรรมเพื่อส่งไปยังมันและต้องรวมข้อมูลทั้งหมดไว้ในอินพุตเพื่อใช้จ่าย P2SH ปรับด้านเอาต์พุตให้เหมาะสมโดยการรวมแฮชความยาวคงที่ของคีย์สาธารณะและสคริปต์ของ multisig ประหยัดค่าธรรมเนียมสําหรับทุกคนที่ส่งไปยังที่อยู่ multisig และทิ้งค่าใช้จ่ายที่เพิ่มขึ้นสําหรับผู้ส่งเท่านั้น SegWit arguably "ปรับให้เหมาะสม" เพิ่มเติมโดยทําให้การใช้จ่าย multisig UTXOs ถูกลงด้วยส่วนลดพยาน Schnorr ใช้การเพิ่มประสิทธิภาพที่เพิ่มขึ้นทั้งหมดนี้ให้ถึงขีดสุด คุณรวมคีย์สาธารณะแต่ละคีย์ไว้ในคีย์เดียว ซึ่งทุกคนสามารถทํางานร่วมกันเพื่อสร้างลายเซ็นเดียวและตรวจสอบได้ สิ่งนี้สร้างการประหยัดต้นทุนอย่างมากสําหรับการใช้ multisig ทั้งหมดรวมถึงเลเยอร์ที่สองเช่น Lightning และ sidechains แบบรวมศูนย์และสร้างประโยชน์ด้านความเป็นส่วนตัวเช่นกันโดยทําให้ multisig UTXOs เหล่านี้แยกไม่ออกจากลายเซ็นเดียว

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

สิกขา _ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT )ก่อนหน้านี้ SIGHASH_NOINPUT( หวังว่าจะเป็นพื้นที่ใหม่ถัดไปที่มาพร้อมกับท่อน้ำ. มันเป็นรูปแบบคีย์สาธารณะ/อัพเกรดธงลายมือ. ธงลายมือระบุส่วนไหนของธุรกรรมที่ลายมือกำลังยอมรับ. ฟังก์ชันนี้มีเพื่อให้คุณสามารถทำอะไรก็ได้เช่นลายมือเพียงแค่ส่วนของข้อมูลนำเข้าและข้อมูลเอาท์พุตของคุณ, แต่อนุญาตให้คนอื่นเพิ่มข้อมูลนำเข้าและข้อมูลเอาท์พุตของตนเองลงในธุรกรรมโดยไม่ทำให้โมฆียง. แต่ในปัจจุบัน, ลายมือต้องยอมรับ UTXO ที่แน่นอนจากธุรกรรมที่แน่นอน. SIGHASH_ANYPREVOUT, ระหว่างสิ่งอื่นๆ, จะทำให้เป็นไปได้ ยอมรับลายมือไปยังสคริปต์ UTXO เท่านั้น, ไม่ใช่ UTXO ที่แน่นอนจริงๆ. นี้ช่วยให้มีวิธีใหม่ )eltoo( ในการสร้างสถานะช่องแสงไลท์ที่ไม่ต้องการคีย์โทษหรือจัดการกับสถานะเก่าๆ โดยอนุญาตให้ฝ่ายถูกโกงยึดเงินได้ทั้งหมด. แทนที่, สถานะช่องปัจจุบันสามารถใช้เงินสถานะช่องเก่าอีกครั้งหากพ้นจากการแข่งขันการสำเร็จการใช้เงินคู่ขาย, การรับรองว่าทุกคนได้ยอดคงเหลือช่องปัจจุบันของตนบนเชนเทียบกับยอดคงเหลือเก่าก่อนหน้า. คุณสามารถทำเช่นนั้นโดยการใช้สคริปต์เดียวกันในสถานที่ที่เหมาะและใช้ SIGHASH_ANYPREVOUT.

นี่จะลดความเสี่ยงมากเกี่ยวกับการที่คุณจะสูญเสียสถานะช่องปัจจุบันซึ่งเป็นผลให้มีการทำธุรกรรมลงโทษโดยใช้เงินของคุณเพื่อข้อผิดพลาดที่ซื่อสัตย์ นอกจากนี้ยังเป็นการเปิดใช้สิ่งมากมายมากขึ้น ตอนนี้เราสามารถมีช่อง Lightning ที่มีผู้ร่วมกิจกรรมมากกว่า 2 คน และยังสามารถเรียง “sub-channels” บนนั้นได้อีกด้วย นอกจากนี้ยังมี SIGHASH_ANYPREVOUT และ eltoo ทำให้เกิด Statechains ได้ นั่นคือชนิดของโครงสร้างช่องระหว่างกลุ่มที่อนุญาตให้ผู้ร่วมกิจกรรมใหม่เข้าและออกอย่างสมบูรณ์นอกเครือข่ายด้วยการสมมติความไว้วางใจว่าเครือข่ายจะไม่มีการค้างคาวกับผู้ร่วมกิจกรรมในอดีตเพื่อที่จะโกงใครให้เสียหาย สิ่งนี้เปิดโอกาสมากมายสำหรับสิ่งที่ฉันเรียกตัวเองว่า “multi-party static UTXO protocols.”

OP_CHECKTEMPLATEVERIFY

OP_CTV เป็นข้อเสนอโดย Jeremy Rubin เพื่อเปิดใช้งานประเภทพื้นฐานของ "covenant" บน บิทคอยน์ ซึ่ง covenant เป็นข้อจำกัดที่ซับซ้อนกว่าการใช้เหรียญในการเซ็นต์จากคีย์บางตัว ประเภทของ covenant ที่ข้อเสนอของ Rubin จะนำมาใช้คือ "template" โดยพื้นฐานแล้วฉะนั้นนี้ช่วยให้สคริปต์ของ UTXO ต้องการให้เอาตัวออกมาที่แน่นอนโดยการทำธุรกรรมที่ใช้เหรียญนี้ ดังนั้นเมื่อ UTXO ถูกสร้างโดยใช้ OP_CTV มันถูกบังคับให้ทำธุรกรรมให้เงินตรงตามที่กำหนดไว้ในสคริปต์ของ UTXO นั้น คุณยังสามารถเชื่อมโยงเหล่านี้เข้าด้วยกันโดยที่หนึ่งใน UTXOs เหล่านี้ถูกบังคับให้สร้างเหรียญอีกไม่กี่เหรียญ ซึ่งต่อมาก็ต้องบังคับให้สร้างเหรียญอีกไม่กี่ เรื่อยไป

สิ่งนี้มีการบังคับใช้ทั่วไปอย่างมหาศาลทั่วทุกแห่ง ในสภาพแวดล้อมที่มีค่าธรรมเนียมสูง UTXO เดียวสามารถทําได้โดยหน่วยงานที่ดูแลซึ่ง ** 100% ภายใต้กฎฉันทามติ ** รับประกันว่าเงินทุนของลูกค้าทั้งหมดจะอยู่ภายใต้การควบคุมของลูกค้าแม้ว่าพวกเขาจะไม่สามารถเข้าถึงได้ทันทีในขณะนี้ สิ่งนี้มีศักยภาพมากมายในการผนึกกําลังกับช่องหลายฝ่าย )channel factories( ในการที่ "ถอนตัว" จํานวนมากที่ทําเช่นนี้สามารถสร้างและใช้เป็นโรงงานช่องได้พร้อมกัน สามารถใช้ OP_CTV เพื่อสร้าง * ช่องทางการชําระเงินที่อย่างน้อยก็ทํางานแบบทิศทางเดียวโดยที่ปลายทางการรับไม่ต้องเข้าร่วมหรือมีคีย์ออนไลน์เพื่อรับการชําระเงิน * )and จําไว้ว่าคุณสามารถซ้อนช่องที่ด้านบนของแต่ละ other( ได้ นอกจากนี้ยังสามารถใช้เพื่ออนุญาตให้ช่องทางเดียวประมวลผล HTLCs ได้มากขึ้นในคราวเดียวโดยการรวมเข้าด้วยกันด้วยเคล็ดลับเดียวกับที่ตัวอย่างแรกที่มีการถอนเงินแบบ custodial ใช้ และอาจสร้างศักยภาพบางอย่างสําหรับ coinjoins ประเภทใหม่

การรวมทุกอย่างเข้าด้วยกัน

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

พวกเขาจะเปิดใช้งานช่องหลายฝ่ายที่มีจํานวนผู้เข้าร่วมที่ไม่มีขอบเขตในทางทฤษฎีซึ่งสามารถซ้อนช่องย่อยไว้ด้านบนกับกลุ่มย่อยที่เล็กกว่าของผู้เข้าร่วมของช่องฐาน ช่องสามารถสร้างขึ้นจาก "โรงงานช่อง" เหล่านี้ที่ช่วยให้ผู้คนได้รับเงินโดยไม่ต้องมีกุญแจออนไลน์สําหรับกระเป๋าเงินร้อน ช่องแบบหลายฝ่ายเหล่านี้สามารถวางซ้อนกันได้ด้านบนของช่องแบบรวมศูนย์ )statechains อนุญาตให้ผู้เข้าร่วมเข้าหรือออกด้วย * กิจกรรมออนเชนเป็นศูนย์ *! และการสร้างช่อง "ประกบ" จะช่วยให้สภาพคล่องสามารถเคลื่อนย้ายได้ค่อนข้างราบรื่นระหว่างช่องทางต่างๆในรูปแบบที่จะช่วยให้ทุกสิ่งที่ผู้คนยังไม่ได้เริ่มคิดจริงๆ

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

นี่เป็นเพียง ส่วนที่ 2 จาก 4 อ่านส่วนถัดไปพรุ่งนี้