Cùng xem qua “giấy vàng” của Nexty

Dũng Trần
tradahacking
Published in
5 min readAug 1, 2018

Hôm nay, cầm trên tay Yellowpaper “hót” nhất trong thời gian gần đây, mình cũng thử tìm hiểu những triết lý ẩn sâu bên trong thiết kế này. Và mình cũng giải thích các thuật ngữ liên quan nêu trong paper.

Proof-of-Authority

Đúng như tên gọi của nó, proof-of-authority là một chính quyền tập trung được vận hành bởi một nhóm nhỏ các nodes đóng vai trò cao hơn các node còn lại trong mạng (thường được gọi là validator/notary node), điều này dẫn tới các vấn đề sau:

  • Các Notary nodes đóng vai trò như một third party và yêu cầu người dùng phải tin tưởng và ủy thác sự an toàn của mạng cho các nodes này.
  • Notary nodes có thể thông đồng nhau để thực hiện double spent, reverse transactions, fork bất cứ khi nào các notary nodes bắt tay với nhau.
  • Người xây dựng hệ thống có thể tạo ra các notary nodes nặc danh để trục lợi.
  • Notary nodes nhận được nhiều đặc quyền đặc lợi từ hệ thống.

Nếu thành thật, Proof-of-Authority là một whitelist các nodes có quyền sinh block mới. Hệ thống có thể gọi là distributed nhưng hoàn toàn không phải decetralized.

Proof-of-Foundation

This is the detail technical paper of Nexty Platform, focusing on describing
the operation of a consensus protocol called Proof of Foundation. Proof of Foundation was inspired by the Proof of Authority introduced by Szilágyi [2017] with improvement from Nexty Platform by introducing a new confirmation system named DCCS — Dual Cryptocurrency Confirmation System to achieve a absolutely decentralized system and bring a highly incentive system for blockchain maintainers.

Đọc phần abstract mình hơi choáng, vì “inspired by the Proof of Authority” nhưng vẫn đảm bảo “absolutely decentralized system”. Theo mình rất khó để một hệ thống sử dụng proof-of-foundation có thể trở thành một hệ thống decentralized vì những lý do sau:

  • Quyền sinh block sẽ không được chia đều cho mọi người như các hệ thống fully decentralized như Bitcoin hay Ethereum.
  • Quyền sinh block mới sẽ nằm trong tay một nhóm nhỏ các nodes trong whitelist.
  • Sealers sẽ là những người nào? tiêu chí gì để chọn họ? whitelist này do ai lập ra? Xét ở điểm này proof-of-foundation còn kém hơn delegated-proof-of-stake, khi mà delegates được voting thông qua decentralized voting.
  • Sealers không cần phải thế chấp, và không bị trừng phạt vậy lấy gì đảm bảo họ sẽ không gian dối? (vấn đề này liên quan tới nothing at stake). Xét điểm này thì proof-of-foundation còn kém hơn proof-of-stake, vì một số proof-of-stake như Ouroboros có thể phát hiện và ngăn chặn nothing at stake.
  • Trong paper không định nghĩa hệ thống sẽ trở thành decentralized thế nào.

Để thêm phần khách quan chúng ta cùng xem liệu “Dual Cryptocurrency Confirmation System” có thể biến hệ thống dùng proof-of-foundation trở thành “absolutely decentralized system” được không.

Dual Cryptocurrency Confirmation System

The DCCS block sealing mechanism will be implemented as in following steps. Firstly, the sealers will be numbered from 1 to n (called “sealing-id”) randomly at the beginning of each sealing round.

Mình đọc đoạn này lại há hốc, shock nhất là “randomly at the beginning of each sealing round”. Như vậy trước khi bạn giải bài toán seal block, bạn phải giải quyết bài toán random của distributed system, vấn đề này rất hóc búa vì nó là một nghịch lý, câu hỏi đặt ra là: Làm thế nào sinh một số ngẫu nhiên, không thể đoán trước hoặc không thể manipulate bởi adversary?.

H1. Random sealeing-id

Như vậy “sealing-id” được đánh số dựa trên việc sắp xếp các hashes (keccak-512) từ check point block number of sealing-round address trong whitelist của từng sealer, sau đó được đánh số từ 1 đến n:

H2. Tạo array list của sealing-id

Sau đó tính toán “sealing-id” của “sealing block ” bằng cách:

H3. Tính toán vị trí của sealing-id

Ví dụ: Block đang đóng là 100, block start của sealing-round là 90, có 5 sealers. Thì ta có: (100–90) % 5 = 0.

H4. Xác định vị trí của sealers

Đoạn này mình xin phép cười xíu, “sealing-id” là từ 1 đến n, σk ∈ [0, n-1], việc không chọn được sealer sẽ lặp lại theo chu kì 𝚷, và “sleaing-id” thứ n sẽ không bao giờ được chọn 🤔.

Theo hình 4 ta học thêm một điều ψk sẽ được dùng như wait time trong round-robin scheduling.

H5. Orphan node

Đọc vào đoạn này ai cũng thấy một triết lý, triết lý này bảo vệ hệ thống và đơn giản hóa trong việc chọn active chain. Kèm theo triết lý này là một sự xuẩn ngốc. Nếu mình là một adversary và mình là Notary node, mình hoàn toàn có thể implement eclipse attacks nhắm vào một nhóm nhỏ trong network. Bằng cách lure họ vào network riêng của mình, và những thay đổi trong network đó hoàn toàn invalid với honest notary nodes.

Kết luận

Về phần ăn chia của “nhóm lợi ích” (a.k.a notary nodes) mình xin được phép không bàn tới, mong quý tác giả nên tham khảo thêm:

1. SCRAPE: Scalable Randomness Attested by Public Entities
2. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol
3. A Simple Publicly Verifiable Secret Sharing Scheme and its Application to Electronic Voting

Trong paper của IOHK thì họ dùng SCRAPE để sinh số ngẫu nhiên, làm tiền đề cho việc chọn slot leader. Ouroboros cũng được thiết kế kỹ lưỡng để phát hiện các adversaries hoặc nothing at stake.

Proof of Foundation thiết kế chưa được tốt, hệ thống không đạt được tiêu chí đề ra là “absolutely decentralized system”. Và việc chọn sealers chưa thực sự hiệu quả và chính xác, paper này là một sự lai tạp giữa proof-of-authority và round-robin.

Có rất nhiều thiết kế thoáng nghĩ là dở hơi, nhưng thực ra bên trong nó luôn ẩn chứa một triết lý và tất nhiên cũng có những triết lý nhưng cốt lõi là sự xuẩn ngốc. — From chiro with 💖

--

--