41 เกี่ยวกับความหลากหลายของประเภทธุรกรรม

แปลโดย : Claude 3 Opus (Pro)

41

เกี่ยวกับความหลากหลายของประเภทธุรกรรม

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

Re: ธุรกรรมและสคริปต์: DUP HASH160 . . . EQUALVERIFY CHECKSIG

Satoshi Nakamoto 17 มิถุนายน 2010, 18:46:08 น.

อ้างอิงจาก: Gavin Andresen 17 มิถุนายน 2010, 11:38:31 น.

ผมกำลังเขียนเครื่องมือเล็ก ๆ ที่แยกส่วนประกอบของไฟล์ wallet.dat ของ Bitcoin ส่วนใหญ่เป็นเพราะผมต้องการเข้าใจให้ดีขึ้นว่า Bitcoin ทำงานอย่างไรกันแน่

และผมเห็นว่าเอาต์พุตของธุรกรรมมีค่า (จำนวนบิตคอยน์) และไบต์จำนวนมากที่ถูกรันผ่านภาษาสคริปต์แบบ Forth ที่สร้างขึ้นใน bitcoin เช่น ['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90EQUALVERIFY CHECKSIG']

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

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

ผมสามารถเขียนโค้ดเพื่อสร้างธุรกรรมพร้อมสคริปต์ที่ถูกต้องใด ๆ ใน TxOut ได้หรือไม่?

เช่น ผมสามารถสร้าง TxOut ด้วยสคริปต์: OP_2DROP OP_TRUE . . . เพื่อสร้างเหรียญที่ทุกคนสามารถใช้จ่ายได้หรือไม่?

และความยืดหยุ่นในประเภทของเหรียญที่สร้างขึ้นคือเหตุผลที่มันถูกเขียนโค้ดในลักษณะนี้ใช่หรือไม่?

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

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

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

การออกแบบรองรับความหลากหลายของธุรกรรมที่เป็นไปได้อย่างมาก ซึ่งผมได้ออกแบบไว้เมื่อหลายปีก่อน ธุรกรรมแบบ escrow, bonded contracts, การอนุญาโตตุลาการของบุคคลที่สาม, ลายเซ็นหลายฝ่าย ฯลฯ หาก Bitcoin ประสบความสำเร็จอย่างยิ่งใหญ่ สิ่งเหล่านี้คือสิ่งที่เราอยากจะสำรวจในอนาคต แต่ทั้งหมดจำเป็นต้องถูกออกแบบไว้ตั้งแต่ต้นเพื่อให้แน่ใจว่าจะเป็นไปได้ในภายหลัง

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

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

ผมรู้ว่านักพัฒนาส่วนใหญ่ไม่ชอบให้ซอฟต์แวร์ของพวกเขาถูกแยก แต่ในกรณีนี้ผมมีเหตุผลทางเทคนิคจริง ๆ

อ้างอิงจาก: gavinandresen เมื่อ 17 มิถุนายน 2010, 19:58:14 น.

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

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

นั่นเป็นหนึ่งในเหตุผลของค่าธรรมเนียมการทำธุรกรรม มีสิ่งอื่น ๆ ที่เราสามารถทำได้หากจำเป็น

อ้างอิงจาก: laszlo เมื่อ 17 มิถุนายน 2010, 18:50:31 น.

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

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

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