BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

Buterin đích thân giải thích các nguyên tắc thiết kế của Serenity và giúp bạn hiểu được sự khéo léo độc đáo đằng sau dự án tráng lệ này!

Đọc bài viết này mất 44 phút
Ethereum 2.0 sử dụng cơ chế Chém (phạt cam kết), tức là những validator bị phát hiện có hành vi sai trái sẽ bị trừng phạt, hình phạt nhẹ nhất là phá hủy ~1% số tiền cam kết và hình phạt nghiêm trọng nhất là phá hủy tài sản của người xác thực. Tất cả các khoản tiền gửi cầm cố.

Bản gốc text Tiêu đề: "Buterin đích thân giải thích các nguyên tắc thiết kế của Serenity, giúp bạn hiểu được sự khéo léo độc đáo đằng sau dự án tráng lệ này!" 》

Tác giả gốc: V God (Bản dịch: Jhonny)

Nguồn gốc: Đồng phục

Nguyên tắc thiết kế thanh thản

▲ Đơn giản: Đặc biệt vì PoS kinh tế tiền điện tử và phân đoạn bậc hai có bản chất phức tạp nên các giao thức phải tối giản nhất có thể trong các quyết định của chúng. Nhằm mục đích đơn giản tối đa. Điều này rất quan trọng vì nó sẽ kích hoạt:

(i) Giảm thiểu chi phí phát triển,

(ii) Giảm rủi ro an toàn do tai nạn của các vấn đề và 

(iii) Giúp các nhà thiết kế giao thức dễ dàng thuyết phục người dùng hơn về tính hợp pháp của việc lựa chọn tham số.

Theo liên kết này [1] để biết thông tin cơ bản. Khi chúng tôi mong muốn đạt được một mức độ chức năng cụ thể thì không thể tránh khỏi một mức độ phức tạp nhất định. Mức độ phức tạp ưu tiên là: độ phức tạp của giao thức Lớp 2> độ phức tạp của việc triển khai máy khách> độ phức tạp của đặc tả giao thức.

▲ Tính ổn định lâu dài: Lý tưởng nhất là nên xây dựng các giao thức cấp thấp hơn để không cần thay đổi giao thức trong 10 năm trở lên và mọi đổi mới cần thiết đều có thể được triển khai ở các cấp cao hơn (triển khai máy khách hoặc giao thức Lớp 2).

▲ Tính đầy đủ: Có thể xây dựng càng nhiều lớp ứng dụng càng tốt trên giao thức.

▲ Bảo vệ chuyên sâu: Giao thức sẽ có thể tiếp tục hoạt động theo nhiều giả định bảo mật có thể có khác nhau (chẳng hạn như các giả định về độ trễ mạng, số lần lỗi, động cơ của người dùng).

▲ Khả năng xác minh của light client : Đã cho một số giả định bảo mật (ví dụ: độ trễ mạng, giới hạn ngân sách của kẻ tấn công, chỉ tồn tại 1/n hoặc một số ít trình xác thực trung thực), khách hàng xác thực dữ liệu O © (lý tưởng nhất là chỉ xác thực chuỗi đèn hiệu) sẽ có thể nhận được Bảo đảm gián tiếp rằng tất cả dữ liệu của toàn bộ hệ thống đều khả dụng và hợp lệ, ngay cả khi bị tấn công 51% (lưu ý: đây là một trong những mục tiêu của "phòng thủ theo chiều sâu").

Sự thỏa hiệp giữa Lớp 1 và Lớp 2

Trước tiên, độc giả có thể đọc hai bài viết trước của tôi: Lớp 1 nên đổi mới trong thời gian ngắn nhưng ít sáng tạo hơn về lâu dài [2] và Sidechains so với Plasma so với Shending [3].

Trong bất kỳ thiết kế giao thức blockchain nào, đều có sự khác biệt giữa việc giới thiệu nhiều tính năng hơn trên Lớp 1 (tức là lớp đồng thuận) với việc xây dựng giao thức Lớp 1 đơn giản hơn và cho phép xây dựng các tính năng đó trên Lớp 2 (tức là lớp ứng dụng). sự cân bằng giữa chúng:

Các đối số hỗ trợ Layer2:

Giảm độ phức tạp của lớp đồng thuận (xem phần "Đơn giản" được đề cập ở trên);

Giảm nhu cầu sửa đổi giao thức lớp (Xem "Tính ổn định lâu dài" được đề cập ở trên):

--Giảm nguy cơ không đạt được sự đồng thuận;

--Giảm khối lượng công việc trong quản trị giao thức và rủi ro chính trị

Linh hoạt hơn và định hình lại theo thời gian Khả năng thực hiện các ý tưởng mới

Các đối số hỗ trợ Layer1:

Giảm nguy cơ tiến độ bị đình trệ do thiếu cơ chế buộc mọi người phải nâng cấp lên giao thức mới (tức là hard fork);

Có thể làm giảm độ phức tạp của toàn bộ hệ thống;

Nếu Lớp1 Nếu không đủ mạnh thì không thể xây dựng được hệ thống Lớp 2 với hiệu năng cần thiết trên Lớp 1 (xem phần “đủ” nêu trên)

Thiết kế của Ethereum 2.0 rất phức tạp, phần lớn là về việc duy trì sự cân bằng giữa Lớp 1 và Lớp 2 một cách cẩn thận. Điều này bao gồm (i) Turing-complete, thực thi mã giàu trạng thái, (ii) khả năng mở rộng về tính hợp lệ và tính toán dữ liệu, và (iii) thời gian xác nhận khối nhanh hơn, đủ để triển khai giao thức] là rất cần thiết vì:

Nếu (i) không được triển khai thì không thể xây dựng các ứng dụng Lớp 2 với mô hình tin cậy mạnh mẽ.

Nếu (ii) không được triển khai, khả năng mở rộng sẽ bị giới hạn ở các công nghệ như kênh trạng thái hoặc Plasma, vốn gặp phải những thách thức về xúc tiến và khóa vốn và/hoặc rút lui trên quy mô lớn.

Nếu (iii) không được thực hiện, thì không thể thực hiện các giao dịch nhanh chóng nếu không sử dụng công nghệ kênh, vốn gặp nhiều thách thức trong việc thúc đẩy và khóa vốn và/hoặc rút vốn quy mô lớn.

Nhưng Ethereum 2.0 cũng cố tình để lại một số tính năng khác cho Lớp 2 triển khai: (i) quyền riêng tư, (ii) ngôn ngữ lập trình cấp cao, (iii) lưu trữ trạng thái có thể mở rộng và (iv) sơ đồ chữ ký. Các tính năng này được để lại cho Lớp 2 vì đây là những lĩnh vực có tốc độ đổi mới nhanh chóng, với nhiều giải pháp hiện có có các tính năng khác nhau và chắc chắn phải đánh đổi để có được các giải pháp mới hơn và tốt hơn. Ví dụ:

Quyền riêng tư: Chữ ký vòng (Chữ ký vòng ) + giá trị bảo mật (giá trị bí mật) so với ZK-SNARK và ZK-STARK, Rollup so với ZEXE, v.v.

Ngôn ngữ lập trình cấp cao: lập trình khai báo so với lập trình mệnh lệnh, cú pháp, tính năng xác minh chính thức, hệ thống loại, tính năng bảo vệ (chẳng hạn như cấm sử dụng các hàm không thuần túy trong biểu thức số học), các tính năng bảo mật được hỗ trợ nguyên gốc, v.v.;

Bộ nhớ trạng thái có thể mở rộng: mô hình tài khoản so với mô hình UTXO (đầu ra giao dịch chưa chi tiêu), các sơ đồ thuê khác nhau, nhân chứng nhánh Merkle thô so với nén SNARK/STARK so với bộ tích lũy RSA, cây Merkle thưa thớt so với cây AVL so với sự mất cân bằng dựa trên mức sử dụng, v.v. .. (ngoài ra còn có các sơ đồ khác nhau để xác minh quá trình chuyển đổi trạng thái).

Lược đồ chữ ký: Chữ ký Schnorr, chữ ký BLS, chữ ký Lamport, v.v.

Tại sao nên sử dụng bằng chứng cổ phần?

Xem:

https://github.com /ethereum/wiki/wiki/Proof-of-Stake-FAQ

https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51

Tại sao nên sử dụng Casper?

Thuật toán đồng thuận Bằng chứng cổ phần (PoS) hiện tại chủ yếu có ba phe:


- Proof of Stake lấy cảm hứng từ Satoshi Nakamoto Các thuật toán (chẳng hạn như Peercoin (Peercoin), NXT (Future Coin), Ouroboros (thuật toán đồng thuận của Cardano) và các thuật toán thực tế khác)

- Thuật toán bằng chứng cổ phần lấy cảm hứng từ PBFT (Dung sai lỗi Byzantine thực tế) (chẳng hạn như Tendermint, Casper FFG , Hotstuff, v.v. Thuật toán)

- CBC Casper (xem [4] và [5] để biết giải thích )

Ở hai phe sau, có một câu hỏi là liệu có nên sử dụng ký quỹ hay không và sử dụng như thế nào tiền gửi (cầm cố) và Chém (tiền phạt tiền gửi). Tất cả ba cơ chế bằng chứng cổ phần đều vượt trội hơn bằng chứng công việc (PoW), nhưng chúng tôi muốn bảo vệ cách tiếp cận được Ethereum 2.0 sử dụng trong bài viết này.

Phạt cam kết ( Chém )

Ethereum 2.0 sử dụng cơ chế Chém (phạt cam kết), tức là những người xác thực bị phát hiện có hành vi sai trái sẽ bị trừng phạt. Hình phạt nhẹ nhất là phá hủy ~1% số tiền cam kết và hình phạt nặng nhất Hình phạt là phá hủy tất cả tiền gửi của người xác nhận.

Chúng tôi bảo vệ việc sử dụng cơ chế Chém thông qua các khía cạnh sau:

Tăng chi phí tấn công: Điều chúng tôi muốn đảm bảo là bất kỳ cuộc tấn công 51% nào vào chuỗi PoS sẽ dẫn đến một khoản phí rất lớn cho kẻ tấn công (chẳng hạn như tiền điện tử trị giá hàng trăm hàng triệu đô la) và hệ thống có thể nhanh chóng phục hồi sau bất kỳ cuộc tấn công nào. Điều này làm cho phép tính tấn công/phòng thủ trở nên rất bất lợi cho kẻ tấn công và thực sự có thể khiến cuộc tấn công phản tác dụng.

Khắc phục tình thế tiến thoái lưỡng nan do người xác minh gây ra: Cách thực tế và trực tiếp nhất để một nút bắt đầu đi chệch khỏi hành vi "trung thực" là bỏ bê nhiệm vụ của mình (ví dụ: người xác minh nên tham gia vào quá trình xác minh, nhưng không tham gia vào quá trình xác minh). xác minh; hoặc ký khi không nên ký, v.v.). Vấn đề nan giải mà các trình xác thực đặt ra được trình bày chi tiết trong [6] và việc khai thác Bitcoin SPV [7] là một ví dụ về điều này đang xảy ra, điều này sẽ dẫn đến những hậu quả rất nghiêm trọng. Hình phạt xác nhận đối với người xác thực không trung thực có thể giúp giảm bớt những tình huống khó xử này.

Một ví dụ tinh tế hơn về điểm 2 ở trên là vào tháng 7 năm 2019, một trình xác nhận trên chuỗi Cosmos đã bị cắt vì ký hai khối xung đột [8]. Kết quả điều tra về sự cố này cho thấy trình xác thực đang chạy một nút chính và một nút dự phòng cùng lúc. Mục đích của trình xác thực là để đảm bảo rằng khi một trong các nút ngoại tuyến thì trình xác thực vẫn đang chạy. nhận được phần thưởng, hai nút tình cờ được khởi động cùng lúc, khiến hai nút ký hai khối trái ngược nhau.

Nếu bạn có cả hai nút chính và Nếu các nút dự phòng trở thành tiêu chuẩn, kẻ tấn công có thể phân vùng mạng blockchain và khiến tất cả các nút chính và nút dự phòng của người xác thực gửi các khối khác nhau, dẫn đến hai khối xung đột được hoàn tất. Hình phạt chém giúp ngăn chặn hành vi này ở mức độ lớn, giảm nguy cơ xảy ra.

Lựa chọn thuật toán đồng thuận

Trong số ba phe về thuật toán đồng thuận PoS được đề cập ở trên, chỉ có hai phe sau (tức là thuật toán đồng thuận lấy cảm hứng từ PBFT và CBC Casper) Có khái niệm về tính hữu hạn, đó là nghĩa là, một khối được xác nhận theo cách này: chỉ khi có một tỷ lệ lớn trình xác nhận (thuật toán lấy cảm hứng từ PBFT yêu cầu ít nhất 1/3 số trình xác nhận, thuật toán CBC Casper yêu cầu Khối sẽ chỉ được đảo ngược khi ít nhất 1/4 của người xác nhận) hoạt động sai và bị cắt giảm theo đó;

Và thuật toán đồng thuận trại đầu tiên (quy tắc chuỗi dài nhất) lấy cảm hứng từ Satoshi Nakamoto không thể đạt được Tính cuối cùng này theo nghĩa này.

Cần lưu ý rằng thuyết xác định yêu cầu phần lớn người xác nhận phải trực tuyến và đây đã là một yêu cầu đã tồn tại trong cơ chế Sharding (sharding), tức là cơ chế Sharding yêu cầu xác minh 2/3 trong mỗi ủy ban bao gồm ngẫu nhiên trình xác nhận Người dùng ký vào liên kết chéo và chỉ khi đó liên kết chéo mới được chuỗi đèn hiệu chấp nhận.

Chúng tôi chọn Casper FFG chỉ vì đây là thuật toán đơn giản nhất có sẵn cho giao thức khi đạt được tính xác định. Chúng tôi hiện đang tích cực khám phá việc chuyển sang CBC Casper trong Giai đoạn 3 của Ethereum 2.0.

Sharding hay tại sao chúng ta ghét siêu nút?

Dành cho Về mặt mở rộng Layer1, một giải pháp thay thế chính cho sharding là sử dụng siêu nút. Các siêu nút yêu cầu mỗi nút đồng thuận phải có một máy chủ mạnh để nút đó có thể xử lý từng giao dịch một cách độc lập. .

Dựa trên trên quy mô Siêu nút một cách thuận tiện vì chúng dễ triển khai: đó là cách tiếp cận tương tự mà nhiều chuỗi khối hiện tại áp dụng, ngoại trừ việc cần nhiều công việc thiết kế phần mềm hơn để xây dựng nó theo cách song song hơn.

Chúng tôi không chọn điều này Những lý do chính để sử dụng siêu nút như sau:

- Rủi ro tập trung nhóm xác thực: Trong một hệ thống dựa trên các siêu nút, việc chạy một nút sẽ yêu cầu chi phí cố định cao, điều này làm hạn chế số lượng người dùng có thể tham gia. Trong khi một số người sẽ phản đối rằng “trong hầu hết các loại tiền điện tử PoW và PoS, sự đồng thuận được kiểm soát bởi 5-20 nhóm (nhóm khai thác hoặc nhóm xác thực) chạy tốt các nút”. tồn tại ngay cả giữa các nhóm có nguồn tài chính mạnh. Nếu chi phí cố định của việc chạy trình xác thực rất cao so với lợi nhuận thì các nhóm lớn hơn có thể đưa ra mức phí rẻ hơn so với các nhóm nhỏ hơn, điều này có thể dẫn đến việc các nhóm nhỏ hơn đó bị vắt kiệt sức và cảm thấy khó khăn. Trong một hệ thống phân đoạn, những người xác thực đặt cược nhiều ETH hơn sẽ cần xác minh nhiều giao dịch hơn, do đó chi phí không cố định.

- Rủi ro tập trung vào đám mây: Trong hệ thống dựa trên siêu nút, người dùng thực hiện Đặt cược tại nhà trở nên không khả thi, vì vậy hầu hết việc đặt cược có nhiều khả năng xảy ra trong môi trường điện toán đám mây. Điều này tạo ra một điểm thất bại duy nhất.

- Giảm khả năng chống kiểm duyệt: if It Người dùng không thể tham gia đồng thuận nếu không đáp ứng yêu cầu về tính toán + băng thông cao, giúp việc phát hiện và kiểm duyệt trình xác nhận trở nên dễ dàng hơn.

- Khả năng mở rộng: in a In the hệ thống siêu nút, khi thông lượng giao dịch tăng lên, các rủi ro nêu trên sẽ tăng theo và hệ thống sharding có thể xử lý sự gia tăng khối lượng giao dịch dễ dàng hơn.

Những rủi ro tập trung hóa này cũng là nguyên nhân của chúng tôi lý do tại sao chúng tôi không cố gắng đạt được độ trễ cực thấp của Ethereum (dưới 1 giây) mà thay vào đó chọn độ trễ vừa phải (tương đối). Trong hệ thống Ethereum 2.0, bạn có thể tham gia bằng cách sử dụng ít hoặc nhiều ETH và sử dụng ít hoặc nhiều sức mạnh tính toán (mặc dù bạn cần phải nhất quán về ETH và sức mạnh tính toán, tức là bạn không thể đặt cược một lượng lớn ETH với sức mạnh tính toán nhỏ (hoặc ngược lại) và chi phí cố định được giảm thiểu, mặc dù chi phí này sẽ tăng theo số lượng ETH bạn đặt cược (một khi bạn đặt cược Nếu số lượng ETH vượt quá 32.768 ETH, thì hầu hết thời gian bạn sẽ bị xác minh tất cả các chuỗi phân đoạn (lưu ý: có tổng cộng 1024 chuỗi phân đoạn và mỗi người xác thực cần cam kết 32 ETH, vì vậy 1024*32=32.768)).

Mô hình an toàn

Mọi người thường nghĩ rằng tính bảo mật của blockchain dựa trên giả định rằng "hầu hết người tham gia đều trung thực", tức là ≥50% người tham gia sẽ tuân theo giao thức đã thiết lập một cách trung thực và sẽ Từ bỏ cơ hội để nổi loạn vì lợi ích cá nhân.

Trên thực tế, (i) "hầu hết người tham gia đều trung thực Giả định này là không thực tế vì người tham gia có thể "lười biếng" và ký các khối mà không xác thực chúng (xem tình huống khó xử của người xác minh [9] và việc khai thác Bitcoin SPV dẫn đến phân nhánh [10]), đây là những tình huống nổi loạn rất phổ biến; nhưng may mắn thay, (ii) các chuỗi khối thường duy trì bản thân thông qua một số mô hình bảo mật (thay vì cho rằng phần lớn người tham gia sẽ trung thực) các tính năng bảo mật.

Một so sánh chung Sự nghiêm ngặt Mô hình security là mô hình đa số hợp lý không phối hợp, tức là những người tham gia sẽ hành động theo lợi ích riêng của mình nhưng số lượng người tham gia phối hợp với nhau sẽ không vượt quá một tỷ lệ nhất định (trong chuỗi PoW đơn giản, tỷ lệ A này là 23,2). % [11]). Một mô hình bảo mật khác nghiêm ngặt hơn là để giải quyết tình huống xấu nhất, tức là khi một người tham gia kiểm soát hơn 50% sức mạnh tính toán hoặc tiền gửi, vấn đề lúc này sẽ trở thành:

(1) tại đây Trong trường hợp này, liệu chúng tôi có thể đảm bảo rằng người xác thực sẽ phải trả chi phí rất cao khi cố gắng phá vỡ toàn bộ chuỗi không?

(2) Chúng ta có thể duy trì những đảm bảo nào vô điều kiện?

Trong chuỗi PoS, Việc chém có thể mang lại sự đảm bảo cho vấn đề đầu tiên ở trên, đó là khi kẻ tấn công cố gắng phá vỡ toàn bộ chuỗi thì sẽ rất tốn kém. Trong một chuỗi khối không có phân đoạn (chẳng hạn như chuỗi Ethereum 1.0 hiện tại), mỗi nút xác minh tất cả các khối sẽ đáp ứng câu hỏi thứ hai ở trên bằng cách cung cấp hai đảm bảo sau: (i) Chuỗi dài nhất là hợp lệ và (ii) chuỗi dài nhất cũng có sẵn (xem lý do cơ bản về tầm quan trọng của "tính sẵn có của dữ liệu" tại liên kết này [12]).

Trong Ethereum 2.0, chúng tôi sử dụng sharding Để đạt được khả năng phòng thủ theo chiều sâu, nghĩa là, bằng cách kết hợp một ủy ban xác thực được chọn ngẫu nhiên, dựa trên mô hình bảo mật mà phần lớn những người xác thực sẽ vẫn trung thực, để đạt được sự đảm bảo về tính hợp lệ và tính sẵn có, đồng thời ngăn chặn điều đó thông qua bằng chứng về quyền giám hộ. Người xác minh lười biếng (tức là nếu người xác minh "lười biếng" " và sẽ phải đối mặt với hình phạt nếu họ không tham gia xác minh), thông qua bằng chứng gian lận và bằng chứng về tính sẵn có của dữ liệu [9] mà không cần phải tải xuống và xác minh tất cả dữ liệu. Phát hiện các chuỗi không hợp lệ và không thể sử dụng được. Điều này sẽ cho phép khách hàng từ chối các chuỗi không hợp lệ và không có sẵn, ngay cả khi chuỗi đó được phần lớn các trình xác thực PoS hỗ trợ.

Khách hàng có thể chuyển một Một cách bảo toàn sự đồng thuận nhất định để phát hiện kiểm duyệt giao dịch (xem [13] để biết chi tiết), nhưng nghiên cứu trong lĩnh vực này vẫn chưa được tích hợp vào lộ trình Ethereum.

Các tính năng bảo mật dự kiến được hiển thị trong bảng sau:

09.jpg

Cơ chế khuyến khích do Casper đặt ra

- Phần thưởng cơ bản (Phần thưởng cơ bản)

Trong mỗi kỷ nguyên (trong Ethereum In 2.0 , mỗi khi 64 khối được tạo ra (khoảng 6,4 phút), được gọi là epoch), mỗi người xác nhận phải thực hiện "chứng thực", tức là bỏ phiếu và ký tên vào đầu chuỗi (đầu chuỗi cũng là khối trên cùng). Nếu "bằng chứng" của người xác minh được đưa vào tiêu đề chuỗi, người xác minh sẽ nhận được phần thưởng, bao gồm năm phần:


Bởi vì "bằng chứng" được bao gồm trong top Phần thưởng nhận được trong khối;


Phần thưởng cho "bằng chứng" rằng điểm kiểm tra kỷ nguyên chính xác được làm rõ (Lưu ý: Vị trí cuối cùng trong mỗi kỷ nguyên được gọi là điểm kiểm tra và vị trí là giao thức Đặt thời gian cần thiết để tạo khối (6 giây));

Phần thưởng cho việc "kiểm chứng" tiêu đề chuỗi chính xác (khối trên cùng);

Phần thưởng cho việc nhanh chóng đưa "bằng chứng" vào chuỗi (nếu "bằng chứng" ở mức 1. Nếu nó được đưa vào chuỗi sau n vị trí, người xác thực sẽ nhận được tất cả phần thưởng; nếu nó được đưa vào chuỗi sau n vị trí, phần thưởng sẽ là 1/n) trên tổng số phần thưởng;

Vì có "bằng chứng" Phần thưởng rõ ràng cho các khối phân mảnh chính xác.

Trong mỗi trường hợp, phần thưởng thực tế được tính như sau. Nếu B là phần thưởng cơ sở và P là tập hợp con của những người xác thực thực hiện thao tác "bằng chứng" bắt buộc thì bất kỳ người xác thực nào thực hiện thao tác được yêu cầu sẽ được thưởng B*P và bất kỳ người xác thực nào lẽ ra phải thực hiện thao tác liên quan nhưng đã không thực hiện Người xác thực không làm như vậy sẽ bị phạt -B. Mục tiêu của cơ chế “thưởng tập thể” này là “nếu ai đó làm tốt hơn thì mọi người đều làm tốt hơn”, từ đó hạn chế yếu tố phá hoại ác ý. (Xem bài viết này [13] để biết mô tả về các yếu tố độc hại và tại sao việc hạn chế chúng lại quan trọng)

Cần lưu ý rằng điều đầu tiên Điểm 4 là một ngoại lệ; phần thưởng này phụ thuộc vào sự chậm trễ trong việc thông qua "bằng chứng" chứ không phải vào hành vi của người xác minh và không có nguy cơ bị phạt.

Bản thân phần thưởng cơ bản B được tính như sau, trong đó D1...Dn là quy mô cam kết của người xác nhận và k là hằng số. Đây là sự thỏa hiệp giữa hai chế độ phổ biến, đó là (i) đặt tỷ lệ phần thưởng cố định, tức là k*Di và (ii) đặt tổng phần thưởng cố định, tức là.

Lý lẽ chính chống lại (i) là đây mô hình mang đến hai khía cạnh không chắc chắn cho mạng: tổng số tiền phát hành là không chắc chắn và tổng số người tham gia đặt cược là không chắc chắn (vì nếu tỷ lệ phần thưởng cố định quá thấp, về cơ bản sẽ không có ai tham gia, điều này đe dọa đến mạng lưới). toàn mạng; và nếu tỷ lệ phần thưởng cố định quá cao, sẽ có quá nhiều người tham gia, khiến số lượng phát hành coin cao bất ngờ).

Lý lẽ chính chống lại (ii) là mô hình này sẽ làm cho mạng dễ bị "tấn công làm nản lòng", xem [13] để biết chi tiết.

Phương pháp khen thưởng cơ bản dung hòa hai phương pháp này và tránh kết quả tồi tệ nhất của mỗi phương pháp.

Người đề xuất khối bao gồm "bằng chứng" trong khối Phần thưởng nhận được sau khối là 1/8 phần thưởng cơ bản, mục đích là khuyến khích người đề xuất khối lắng nghe thông tin nhiều nhất có thể và chấp nhận càng nhiều thông tin càng tốt.



Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

举报 Báo lỗi/Báo cáo
Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi