ชื่อเรื่องเดิม: "Having a safe CEX: proof of solvency and beyond》

ชื่อเรื่องเดิม: "

ผู้เขียนต้นฉบับ: Vitalik Buterin

การรวบรวมข้อความต้นฉบับ: Double Spending (@doublespending)

ขอขอบคุณเป็นพิเศษสำหรับ Balaji Srinivasan และทีมงานที่ Coinbase, Kraken และ Binance สำหรับการสนทนาของพวกเขา

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

มีความทะเยอทะยานมากกว่านั้น การแลกเปลี่ยนสามารถสร้างระบบที่เงินของผู้ฝากไม่สามารถถอนออกได้โดยไม่ได้รับความยินยอมจากพวกเขา เราสามารถลองสำรวจขอบเขตระหว่าง CEX มืออาชีพที่ "ไม่ทำชั่ว" กับ DEX บนเครือข่ายที่ไม่มีประสิทธิภาพซึ่ง "ทำชั่วไม่ได้" แต่รั่วไหลความเป็นส่วนตัว โพสต์นี้จะเจาะลึกความพยายามทางประวัติศาสตร์ในการทำให้ CEX ไร้ความน่าเชื่อถือมากขึ้น ข้อจำกัดของเทคโนโลยี และวิธีการที่ทรงพลังในการพึ่งพาเทคนิคขั้นสูง เช่น ZK-SNARK

ตารางยอดคงเหลือและต้นไม้ Merkle: หลักฐานการชำระคืนแบบดั้งเดิม

ความพยายามแรกสุดของ Exchange ในการใช้การเข้ารหัสเพื่อพิสูจน์ว่าพวกเขาไม่ได้หลอกลวงผู้ใช้นั้นมีมาช้านาน ในปี 2554 MtGox ซึ่งเป็นบริษัทแลกเปลี่ยน bitcoin ที่ใหญ่ที่สุดในขณะนั้น ได้พิสูจน์ว่าพวกเขาเป็นเจ้าของเงินโดยการส่งธุรกรรมที่ย้าย 424,242 BTC ไปยังที่อยู่ที่เผยแพร่ล่วงหน้า ในปี 2013 การอภิปรายเริ่มต้นขึ้นเกี่ยวกับวิธีแก้ปัญหาอีกด้านหนึ่ง: การพิสูจน์ขนาดรวมของเงินฝากของผู้ใช้ หากคุณพิสูจน์ได้ว่าเงินฝากของผู้ใช้เท่ากับ X (หลักฐานหนี้สิน) และพิสูจน์ได้ว่าคุณมีคีย์ส่วนตัวสำหรับโทเค็น X (หลักฐานสินทรัพย์) แสดงว่าคุณแสดงหลักฐานการละลาย: คุณพิสูจน์ว่าการแลกเปลี่ยนมีเงินเพียงพอที่จะชำระคืน ผู้ฝากเงิน

วิธีที่ง่ายที่สุดในการแสดงหลักฐานการฝากเงินคือการเผยแพร่รายชื่อ ผู้ใช้ทุกคนสามารถตรวจสอบยอดคงเหลือในรายการและทุกคนสามารถตรวจสอบรายการทั้งหมดได้: (i) ยอดคงเหลือแต่ละรายการไม่ติดลบ (ii) ยอดรวมคือจำนวนเงินที่ประกาศแน่นอนว่านี่เป็นการทำลายความเป็นส่วนตัว เราจึงสามารถเปลี่ยนโครงร่างได้เล็กน้อย: เผยแพร่

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

สีเขียว: โหนดของชาร์ลี สีน้ำเงิน: Charlie ได้รับโหนดสำหรับการรับรอง สีเหลือง: โหนดรูท ประกาศให้ทุกคนทราบ

เทคโนโลยี Merkle tree จะใส่ตารางยอดคงเหลือของผู้ใช้ไว้ใน Merkle sum tree ใน Merkle sum tree แต่ละโหนดเป็นคู่ โหนดลีฟที่อยู่ด้านล่างแสดงถึงยอดคงเหลือของผู้ใช้แต่ละรายและแฮชแบบเค็มของชื่อผู้ใช้ ในแต่ละโหนดระดับที่สูงกว่า ยอดคงเหลือคือผลรวมของยอดคงเหลือของสองโหนดด้านล่าง และแฮชคือแฮชของสองโหนดด้านล่าง การพิสูจน์ผลรวมของ Merkle เช่นเดียวกับการพิสูจน์ของ Merkle คือ "สาขา" ที่ประกอบด้วยโหนดน้องสาวทั้งหมดบนเส้นทางจากโหนดใบไม้ไปยังโหนดรูท

# The function for computing a parent node given two child nodes

def combine_tree_nodes(L, R):

L_hash, L_balance = L

R_hash, R_balance = R

assert L_balance >= 0 and R_balance >= 0 

new_node_hash = hash(

L_hash + L_balance.to_bytes( 32, 'big') +

R_hash + R_balance.to_bytes( 32, 'big')

)

return (new_node_hash, L_balance + R_balance)

# Builds a full Merkle tree. Stored in flattened form where

# node i is the parent of nodes 2 i and 2 i+ 1 

def build_merkle_sum_tree(user_table: "List[(username, salt, balance)]"):

tree_size = get_next_power_of_ 2(len(user_table))

tree = (

[None] * tree_size +

[userdata_to_leaf(*user) for user in user_table] +

[EMPTY_LEAF for _ in range(tree_size - len(user_table))]

)

for i in range(tree_size - 1, 0, -1):

tree[i] = combine_tree_nodes(tree[i* 2 ], tree[i* 2+ 1 ])

return tree

# Root of a tree is stored at index 1 in the flattened form

def get_root(tree):

return tree[ 1 ]

# Gets a proof for a node at a particular index

def get_proof(tree, index):

branch_length = log 2(len(tree)) - 1 

# ^ = bitwise xor, x ^ 1 = sister node of x

index_in_tree = index + len(tree) // 2 

return [tree[(index_in_tree // 2**i) ^ 1 ] for i in range(branch_length)]

# Verifies a proof (duh)

def verify_proof(username, salt, balance, index, user_table_size, root, proof):

leaf = userdata_to_leaf(username, salt, balance)

branch_length = log 2(get_next_power_of_ 2(user_table_size)) - 1 

for i in range(branch_length):

if index & ( 2**i):

leaf = combine_tree_nodes(proof[i], leaf)

else:

leaf = combine_tree_nodes(leaf, proof[i])

return leaf == root

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

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

ความละเอียดอ่อนที่สำคัญของโครงการนี้คือความเป็นไปได้ของยอดคงเหลือติดลบ: หากการแลกเปลี่ยนที่มียอดผู้ใช้ 1,390 ETH แต่มีสำรองเพียง 890 ETH พยายามชดเชยโดยการเพิ่มยอดคงเหลือ -500 ETH ภายใต้บัญชีปลอมที่ใดที่หนึ่งในต้นไม้ ฉันควรทำอย่างไร? ความเป็นไปได้นี้ไม่ได้ทำลายโครงร่าง ซึ่งเป็นเหตุผลที่เราจงใจใช้ Merkle sum tree แทน Merkle tree ปกติ สมมติว่า Henry เป็นบัญชีปลอมที่ถูกควบคุมโดยบริษัทแลกเปลี่ยน และบริษัทแลกเปลี่ยนใส่ -500 ETH ไว้:

การตรวจสอบของ Greta จะไม่ผ่าน: เมื่อการแลกเปลี่ยนจะต้องให้โหนดของ Henry ที่มียอดคงเหลือ -500 ETH เธอจะปฏิเสธโหนดที่ไม่ถูกต้อง อีฟและเฟร็ดจะล้มเหลวในการตรวจสอบ เนื่องจากโหนดกลางเหนือเฮนรี่มียอดคงเหลือ -230 ETH ดังนั้นโหนดนี้ก็ไม่ถูกต้องเช่นกัน! เพื่อให้การยักยอกไม่ถูกตรวจพบ การแลกเปลี่ยนทำได้เพียงหวังว่าครึ่งขวาของต้นไม้จะไม่ถูกตรวจสอบเพื่อพิสูจน์ความสมดุล

หากการแลกเปลี่ยนสามารถแยกผู้ใช้ที่มี 500 ETH ที่ไม่กังวลกับการตรวจสอบหลักฐานของยอดเงิน หรือผู้ที่ไม่เชื่อพวกเขาเมื่อพวกเขาบ่นว่าไม่ได้รับหลักฐานของยอดเงินคงเหลือ การแลกเปลี่ยนก็สามารถหลีกเลี่ยงได้ อย่างไรก็ตาม การแลกเปลี่ยนก็สามารถบรรลุผลเช่นเดียวกันได้โดยการยกเว้นผู้ใช้เหล่านี้จากแผนผังผลรวมของ Merkle ดังนั้น หากพิจารณาเฉพาะในแง่ของการพิสูจน์หนี้สิน เทคโนโลยีต้นไม้ของ Merkle ตอบสนองความต้องการโดยพื้นฐาน แต่คุณลักษณะด้านความเป็นส่วนตัวยังไม่เหมาะ คุณสามารถใช้ Merkle tree อย่างละเอียดเพื่อปรับปรุงได้ เช่น ใช้ satoshi หรือ wei เป็น leaf node อิสระ อย่างไรก็ตาม ด้วยการใช้เทคโนโลยีขั้นสูง สามารถทำได้ดียิ่งขึ้น

การใช้ ZK-SNARK เพื่อปรับปรุงความเป็นส่วนตัวและความทนทาน

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

เราสามารถใส่เงินฝากของผู้ใช้ทั้งหมดลงในแผนผัง Merkle (หรือข้อผูกมัด KZG ที่ง่ายกว่า) และใช้ ZK-SNARK เพื่อพิสูจน์ว่ายอดคงเหลือทั้งหมดในแผนผังไม่เป็นลบ และเพิ่มมูลค่าที่อ้างสิทธิ์บางส่วน หากเราเพิ่มเลเยอร์ของการแฮชเพื่อความเป็นส่วนตัว Merkle fork (หรือหลักฐาน KZG) ที่ส่งไปยังผู้ใช้แต่ละคนจะไม่เปิดเผยยอดคงเหลือของผู้ใช้รายอื่น

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

เราสามารถพิสูจน์ผลรวมของเครื่องชั่งใน KZG ข้างต้นและการไม่เป็นลบของเครื่องผ่าน ZK-SNARK เฉพาะ นี่คือตัวอย่างง่ายๆ เราแนะนำพหุนามเสริม I(x) ที่ "สร้างยอดดุลของผู้ใช้ทุกๆ บิต" (เพื่อเป็นตัวอย่าง สมมติว่ายอดคงเหลือต่ำกว่า 2 15 ) โดยทุกๆ ตำแหน่งที่ 16 จะติดตามความแตกต่างที่รับประกันว่าเมื่อยอดจริงเท่านั้น รวมเท่ากับอ้างว่าผลรวมเท่ากับค่าจะเป็น 0 ถ้า z เป็นรากดั้งเดิมของลำดับที่ 128 เราสามารถพิสูจน์ได้ว่าสมการนี้ประกอบด้วย:

[ 1 ] หมายเหตุผู้แปล: การตีความสมการพหุนามนี้

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

ด้วยสมการเพิ่มเติมเพียงเล็กน้อย ระบบข้อจำกัดสามารถปรับให้เข้ากับการตั้งค่าที่ซับซ้อนมากขึ้นได้ ตัวอย่างเช่น ในระบบการซื้อขายที่มีเลเวอเรจ เป็นที่ยอมรับได้สำหรับผู้ใช้แต่ละคนที่มียอดคงเหลือติดลบ แต่เฉพาะในกรณีที่พวกเขามีสินทรัพย์ค้ำประกันเพียงพอที่จะครอบคลุมหนี้สินของพวกเขา SNARK สามารถใช้เพื่อพิสูจน์ข้อจำกัดที่ซับซ้อนมากขึ้น ทำให้ผู้ใช้มั่นใจได้ว่า Exchange ไม่สามารถยกเว้นผู้ใช้บางคนจากกฎอย่างลับๆ ได้ ซึ่งจะเป็นภัยต่อทรัพย์สินของผู้ใช้ในระยะยาว ประโยชน์ของการพิสูจน์ความรับผิดของ ZK นี้ไม่จำกัดเฉพาะเงินฝากของผู้ใช้ในการแลกเปลี่ยน แต่ยังสามารถใช้ในสถานการณ์การให้ยืมที่หลากหลายขึ้น ใครก็ตามที่นำเงินกู้ออกมาให้บันทึกเป็นพหุนามหรือต้นไม้ที่มีเงินกู้นั้น และรูทจะถูกเผยแพร่บนเครือข่าย สิ่งนี้จะช่วยให้ทุกคนที่กำลังมองหาเงินกู้สามารถแสดงหลักฐานที่ไม่มีความรู้แก่ผู้ให้กู้ได้ว่าไม่ได้กู้เงินอื่นมากเกินไป ในที่สุด นวัตกรรมทางกฎหมายอาจทำให้สินเชื่อที่กระทำในลักษณะนี้มีลำดับความสำคัญสูงกว่าสินเชื่อที่ไม่มีข้อผูกมัด นี้อยู่กับเราใน"Decentralized Society: การค้นหาจิตวิญญาณของ Web3"

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

หลักฐานแสดงทรัพย์สิน

เวอร์ชันที่ง่ายที่สุดของ Proof of Assets คือโปรโตคอลที่เราเห็นด้านบน: เพื่อพิสูจน์ว่าคุณถือโทเค็น X คุณเพียงแค่ย้าย X โทเค็นในเวลาที่กำหนดไว้หรือแสดงข้อความ "เงินเหล่านี้เป็นของ Binance" ในการทำธุรกรรม เพื่อหลีกเลี่ยงการเสียค่าธรรมเนียมการทำธุรกรรม คุณสามารถลงชื่อในข้อความออฟไลน์ได้ ทั้ง Bitcoin และ Ethereum มีมาตรฐานข้อความลายเซ็นแบบออฟไลน์

• มีปัญหาในทางปฏิบัติสองประการเกี่ยวกับเทคนิคการพิสูจน์ทรัพย์สินอย่างง่ายนี้:

• การจัดการกระเป๋าเงินเย็น

การใช้หลักประกันซ้ำ

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

การแลกเปลี่ยนสามารถใช้วิธีการต่อไปนี้:

● รักษาที่อยู่สาธารณะระยะยาว การแลกเปลี่ยนสร้างที่อยู่หลายรายการ ออกหลักฐานความเป็นเจ้าของของแต่ละที่อยู่เพียงครั้งเดียว และนำที่อยู่เหล่านี้กลับมาใช้ใหม่ นี่เป็นวิธีแก้ปัญหาที่ง่ายที่สุด แม้ว่าจะเพิ่มข้อจำกัดบางประการในแง่ของความปลอดภัยและความเป็นส่วนตัว

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

● แนวทาง ZKP ที่ซับซ้อนยิ่งขึ้น ตัวอย่างเช่น Exchange สามารถตั้งค่า 1/2 หลายลายเซ็นสำหรับที่อยู่ทั้งหมด หนึ่งในที่อยู่เหล่านี้มีคีย์ที่แตกต่างกัน และอีกอันมีคีย์เดียวกันด้วยวิธีที่ซับซ้อนแต่ปลอดภัย (เช่น 12/16 หลายลายเซ็น) เพื่อจัดเก็บเวอร์ชันตาบอดสำรองฉุกเฉินที่สำคัญ เพื่อรักษาความเป็นส่วนตัวและหลีกเลี่ยงการเปิดเผยที่อยู่ทั้งหมด การแลกเปลี่ยนยังสามารถเรียกใช้การพิสูจน์ที่ไม่มีความรู้บนบล็อกเชนเพื่อพิสูจน์ยอดรวมของที่อยู่บนเชนในรูปแบบนั้น

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

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

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

พลาสมาและวาลิเดียม: เราจะบรรลุ CEX ที่ไม่มีการจัดการได้หรือไม่

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

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

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

OmiseGo พยายามสร้างการแลกเปลี่ยนแบบกระจายอำนาจตามโปรโตคอลนี้ แต่ตั้งแต่นั้นมาพวกเขาก็ย้ายไปทำสิ่งอื่น - และสำหรับเรื่องนั้น Plasma Group กับโครงการ Optimism ที่นำเสนอในแง่ดีของพวกเขา

การอภิปรายในปี 2018 เกี่ยวกับข้อจำกัดของ Plasma (เช่น การจัดระเบียบโทเค็นการพิสูจน์) ทำให้เกิดข้อสงสัยพื้นฐานเกี่ยวกับความมีชีวิตของ Plasma นับตั้งแต่การอภิปรายเกี่ยวกับ Plasma ถึงจุดสูงสุดในปี 2018 ZK-SNARK มีความเป็นไปได้มากขึ้นสำหรับกรณีการใช้งานที่เกี่ยวข้องกับการขยายตัว ดังที่เราได้กล่าวไว้ข้างต้น ZK-SNARK ได้เปลี่ยนแปลงทุกอย่าง

Plasma เวอร์ชันใหม่กว่าคือสิ่งที่ Starkware เรียกว่า validium: โดยพื้นฐานแล้วจะเหมือนกับ ZK-rollup ยกเว้นข้อมูลจะถูกเก็บไว้นอกเครือข่าย โครงสร้างนี้ใช้ได้กับกรณีการใช้งานหลายกรณี และเป็นไปได้ว่าใช้ได้กับทุกสถานการณ์ที่เซิร์ฟเวอร์ส่วนกลางจำเป็นต้องพิสูจน์ว่ารันโค้ดได้อย่างถูกต้อง ใน Validium ตัวดำเนินการไม่สามารถขโมยเงินได้ แต่ขึ้นอยู่กับรายละเอียดการใช้งานเฉพาะ เงินทุนของผู้ใช้บางส่วนอาจติดขัดหากตัวดำเนินการหายไป

ตอนนี้มันดูดีมาก: CEX และ DEX นั้นยังห่างไกลจากทั้งสองอย่าง ปรากฎว่ามีตัวเลือกมากมาย รวมถึงรูปแบบต่างๆ ของการรวมศูนย์แบบไฮบริด ซึ่งคุณจะได้รับประโยชน์บางอย่าง เช่น ประสิทธิภาพ แต่ก็ยังมี cryptos จำนวนมาก การรับประกันทางวิชาการสามารถ ป้องกันพฤติกรรมที่เป็นอันตรายส่วนใหญ่โดยตัวดำเนินการแบบรวมศูนย์

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

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

วิธีแก้ปัญหาระยะยาวในอุดมคติคือการพึ่งพาการดูแลตนเอง และผู้ใช้สามารถใช้เทคโนโลยีต่างๆ เช่น multi-sig และ social recovery wallets ได้อย่างง่ายดายในอนาคตเพื่อช่วยจัดการกับเหตุฉุกเฉิน ในระยะสั้น มีสองทางเลือกที่ชัดเจนซึ่งมีต้นทุนและผลประโยชน์ต่างกัน:

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

สรุป: มองหาการแลกเปลี่ยนที่ดีกว่าในอนาคต

ในระยะสั้น มีการแลกเปลี่ยนที่ชัดเจนสองประเภท: การแลกเปลี่ยนแบบคุมขังและการแลกเปลี่ยนแบบไม่ต้องดูแล ปัจจุบัน หมวดหมู่หลังคือ DEX เช่น Uniswap และในอนาคต เราอาจเห็น CEXs ถูกจำกัดโดยการเข้ารหัส ซึ่งเงินของผู้ใช้จะถูกเก็บไว้ในลักษณะที่คล้ายกับ Validium Smart Contract เรายังอาจเห็นการแลกเปลี่ยนแบบกึ่งคุมขังซึ่งเราไว้วางใจการจัดการสกุลเงิน fiat ของพวกเขามากกว่าสกุลเงินดิจิทัล

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

ในระยะยาว ฉันหวังว่าเราจะก้าวไปสู่ทิศทางที่การแลกเปลี่ยนทั้งหมดไม่มีการดูแล อย่างน้อยก็เมื่อพูดถึง cryptocurrencies การกู้คืนกระเป๋าเงินจะมีอยู่และอาจต้องใช้ตัวเลือกการกู้คืนแบบรวมศูนย์สำหรับผู้ใช้ใหม่ที่มีเงินทุนขนาดเล็กและสถาบันที่ต้องการการจัดการดังกล่าวด้วยเหตุผลทางกฎหมาย แต่สามารถทำได้ที่เลเยอร์กระเป๋าเงินแทนที่จะเป็นการแลกเปลี่ยน ในแง่ของสกุลเงินตามกฎหมาย การเคลื่อนไหวระหว่างระบบธนาคารแบบดั้งเดิมและระบบนิเวศของสกุลเงินดิจิทัลสามารถดำเนินการให้เสร็จสิ้นได้ผ่านกระบวนการเข้าและออกของกองทุนพื้นเมืองของเหรียญ Stablecoin ที่ได้รับการสนับสนุนสินทรัพย์ เช่น USDC อย่างไรก็ตาม เรายังมีหนทางอีกยาวไกล

[1] หมายเหตุของผู้แปล:

➤ ทุกๆ 16 หลักแสดงถึงผู้ใช้ (15 หลักแรกแสดงถึงยอดคงเหลือของผู้ใช้ และหลักสุดท้ายแสดงถึงส่วนต่างระหว่างผลรวมของยอดคงเหลือของผู้ใช้กับใบแจ้งยอดจนถึงปัจจุบัน) เราจะเห็นว่าตัวอย่างข้างต้นแสดงถึงผู้ใช้สองคน (ผู้อ่านต้องการข้อมูลเชิงลึกที่นี่)

➤ ยอดผู้ใช้เฉลี่ยที่อ้างสิทธิ์: 185

➤ ยอดคงเหลือของผู้ใช้ 1: 20 -> 000 0000 0001 0100

ความแตกต่าง: 20 - 185 = -165

➤ ยอดคงเหลือของผู้ใช้ 2: 50 -> 000 0101 0011 0010

ความแตกต่าง: -165 + 50 -185 = -300

➤ หลังจากผ่านผู้ใช้ทั้งหมดแล้ว ความต้องการยอดคงเหลือของผู้ใช้คนสุดท้ายคือ 0

➤ คำอธิบายของสมการทั้งสี่

สมการที่ 1: ค่าเริ่มต้นของการเรียกซ้ำคือ 0

สมการที่ 2: ยอดคงเหลือของผู้ใช้แต่ละคนต้องสอดคล้องกับข้อผูกพันของ KZGสมการที่ 3: สูตรแบบเรียกซ้ำสำหรับยอดดุลของผู้ใช้แต่ละคน ยอดดุลจำกัดคือ >= 0 และ< 2 14 ，

< 2 14 (กล่าวกันว่ายอดคงเหลือ < 2 15 ควรเป็นข้อผิดพลาดทางธุรการ เนื่องจากตามสมการที่ 3 สูตรแบบเรียกซ้ำมีค่าเพียง 14 ค่า I(zi)

ลิงค์ต้นฉบับ

ลิงค์ต้นฉบับ