B-money

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

B-money

B-money resembled Bit Gold in important ways—though it differed in others.

Like Bit Gold, b-money would essentially exist on a ledger (which Szabo had called a “registry”). This ledger would list public keys, and specify the amount of currency units attributed to each public key. To transfer the electronic cash, users would cryptographically sign a message stating how many currency units were being spent from the corresponding public key, and to which public key they were spent. If the transaction was valid (the public key had sufficient funds and the signature matched), the ledger would be updated accordingly.

Like Szabo, Dai laid a strong emphasis on the importance of contracts. B-money was designed to facilitate the effecting of contracts, and a significant chunk of the proposal was dedicated to explaining the tasks of arbitrators in dispute resolution. (Although it wasn’t quite the autonomous smart contracts Szabo had originally envisioned, there were some cryptographic safeguards in place to prevent certain forms of cheating.)

Szabo had also been able to convince Wei Dai that trust-minimization was essential. Trusted third parties are security holes, Dai agreed, and he concluded that an electronic cash system shouldn’t depend on any single entity to track user balances, facilitate transactions, or prevent double-spends.

Instead, Dai came up with two alternative solutions.

The first b-money variant was especially ambitious. In this variant, instead of a central entity, all users of the system would maintain individual copies of the ledger. For every new b-money transaction, each user would individually check its validity, and update their own version of the ledger if the transaction checked out. As long as everyone would stay up to date, the ledgers should remain synchronized across all users.

In theory, the great benefit of such a distributed system is that it would be impossible to corrupt. If someone would for example falsely attribute too much money to their own public keys, this simply wouldn’t affect anyone else; all other ledgers would remain unchanged. If the cheater were to try to spend his spoofed cash, no one else would consider that transaction as valid. Like with Scott Stornetta and Stuart Haber’s time-stamping solution, everyone would keep everyone else honest.

It made distributing the ledger across all users an ideal solution—in theory.

Unfortunately, Wei Dai knew, it wasn’t going to be possible in practice: to prevent double-spends, the system required a “synchronous and unjammable anonymous broadcast channel.” Only if all users could be sure they received all the same transactions in the exact same order, could everyone be confident that their ledgers were synchronized, and that a payment they’d receive would be registered by everyone else as well. This seemed unworkable: double-spend transactions could be sent to different parts of the network simultaneously, while unreliable participants could simply lie about the order of transactions they received.

Or in technical terms: Wei Dai’s first solution ignored the Byzantine Generals Problem.

This is why Dai came up with a second solution in the same proposal.

In this second version of the b-money system, not everyone would maintain a version of the ledger. Rather, the system would consist of two types of participants: regular users and “servers.” Much like the “property club” from Szabo’s Bit Gold proposal, only these servers would maintain the b-money ledgers. To make sure that a transaction went through, regular users would have to check with a random subset of the servers, and only consider a payment final if all these servers recognized it.

Of course, this did reintroduce some trust back into the system. The servers could potentially collude to block transfers, double-spend transactions, possibly steal funds, or even create money for themselves outright.

Wei Dai therefore suggested a way to keep the servers honest.

“Each server is required to deposit a certain amount of money in a special account to be used as potential fines or rewards for proof of misconduct,” he proposed. “Also, each server must periodically publish and commit to its current money creation and money ownership databases. Each participant should verify that his own account balances are correct and that the sum of the account balances is not greater than the total amount of money created.”

However, the b-money proposal did not go into detail on any of these solutions. Perhaps most problematically, Dai didn’t explain who would get to decide if misconduct took place, if it wasn’t decided by the (colluding) servers themselves, or how the fines could be enforced. In much the same way that Bit Gold had not quite provided a solution to settle disputes between servers, b-money hadn’t done so either.

บี-มันนี่

B-money มีลักษณะคล้ายกับ Bit Gold ในแง่ที่สำคัญ แม้ว่าจะแตกต่างกันในบางด้านก็ตาม

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

เช่นเดียวกับ Szabo, Dai ให้ความสำคัญอย่างมากกับความสำคัญของสัญญา B-money ได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการทำให้สัญญามีผลบังคับใช้ และมีส่วนสำคัญในข้อเสนอที่ใช้อธิบายหน้าที่ของอนุญาโตตุลาการในการระงับข้อพิพาท (แม้ว่ามันจะไม่ใช่สัญญาอัจฉริยะแบบอัตโนมัติที่ Szabo ได้วิสัยทัศน์ไว้ในตอนแรกทีเดียว แต่ก็มีการป้องกันทางเข้ารหัสลับบางอย่างเพื่อป้องกันการโกงบางรูปแบบ)

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

แทนที่จะทำเช่นนั้น Dai คิดค้นวิธีแก้ปัญหาสองทางเลือก

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

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

การกระจายสมุดบัญชีไปยังผู้ใช้ทุกคนจึงเป็นวิธีแก้ปัญหาที่เหมาะสมในทางทฤษฎี

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

หรือในแง่เทคนิค: โซลูชันแรกของ Wei Dai ละเลยปัญหาของนายพลไบแซนไทน์ (Byzantine Generals Problem)

นี่คือเหตุผลที่ Dai เสนอโซลูชันที่สองในข้อเสนอเดียวกัน

ในระบบ b-money เวอร์ชันที่สองนี้ ไม่ใช่ทุกคนที่จะเก็บรักษาเวอร์ชันของสมุดบัญชี แต่ระบบจะประกอบด้วยผู้เข้าร่วมสองประเภท: ผู้ใช้ทั่วไปและ "เซิร์ฟเวอร์" คล้ายกับ "สโมสรทรัพย์สิน" จากข้อเสนอ Bit Gold ของ Szabo มีเพียงเซิร์ฟเวอร์เหล่านี้เท่านั้นที่จะเก็บรักษาสมุดบัญชี b-money เพื่อให้แน่ใจว่าธุรกรรมดำเนินไป ผู้ใช้ทั่วไปจะต้องตรวจสอบกับเซิร์ฟเวอร์กลุ่มย่อยแบบสุ่ม และถือว่าการชำระเงินสมบูรณ์ก็ต่อเมื่อเซิร์ฟเวอร์ทุกตัวรับรู้ธุรกรรมนั้น

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

ดังนั้น Wei Dai จึงแนะนำวิธีที่จะทำให้เซิร์ฟเวอร์ซื่อสัตย์

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

อย่างไรก็ตาม ข้อเสนอของ b-money ไม่ได้เจาะลึกในรายละเอียดของวิธีแก้ปัญหาเหล่านี้ บางทีปัญหาที่ใหญ่ที่สุดคือ Dai ไม่ได้อธิบายว่าใครจะเป็นผู้ตัดสินว่ามีการประพฤติมิชอบเกิดขึ้นหรือไม่ หากไม่ได้รับการตัดสินโดยเซิร์ฟเวอร์ (ที่สมรู้ร่วมคิด) เอง หรือจะบังคับใช้ค่าปรับได้อย่างไร ในทำนองเดียวกับที่ Bit Gold ยังไม่ได้ให้วิธีแก้ปัญหาที่แท้จริงในการระงับข้อพิพาทระหว่างเซิร์ฟเวอร์ b-money ก็ยังไม่ได้ทำเช่นกัน