Echo: Khu phức hợp Yuliang của Casper FFG và Casper CBC

Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ETHfans)Lưu ý của biên tập viên: Bài viết này đến từ

Bài viết này là bản dịch của Qiu Jun, một thành viên của cộng đồng Taipei Ethereum Meetup, từ một tweet dài của Vitalik giới thiệu về sự phát triển của Casper vào tháng 8 năm 2018. Một năm sau, quy tắc lựa chọn fork của Eth2.0 đã được xác định là LMD Ghost, không phải IMD Ghost, mà Vitalik đã bày tỏ sở thích của mình trong dòng tweet dài này, nhưng lịch sử phát triển của Casper được đề cập trong bài viết vẫn chứa đầy thông tin chi tiết.

lời tựa

tiêu đề phụ

lời tựa

Các văn bản sau đây bắt đầu.

Giới thiệu

Giới thiệu

Tôi sẽ sử dụng một loạt các tweet để giải thích lịch sử/dòng/tiến trình nghiên cứu của thỏa thuận đồng thuận Ethereum Casper, bao gồm cuộc tranh luận giữa FFG và CBC, việc chuyển đổi mô hình lai sang PoS đầy đủ, vai trò của tính ngẫu nhiên, các cân nhắc thiết kế của cơ chế đồng thuận, và các vấn đề khác.

tiêu đề phụ

Không có gì bị đe dọa và các cuộc tấn công từ xa

Nghiên cứu về bằng chứng cổ phần trong Ethereum bắt đầu với thỏa thuận Slasher vào tháng 1 năm 2014. Mặc dù thuật toán Slasher không lý tưởng lắm nhưng nó giới thiệu một số khái niệm quan trọng, đặc biệt là việc sử dụng các hình phạt để giải quyết “vấn đề không có gì bị đe dọa (Nothing-at-Stake Problem)”. Tuy nhiên, các hình phạt mà tôi đã sử dụng khá nhỏ, chỉ là hủy phần thưởng biểu quyết. Vlad Zamfir đã tham gia vào giữa năm 2014 và anh ấy đã nhanh chóng giới thiệu phương pháp yêu cầu người xác thực phải đặt cọc. Khoản tiền gửi là một con số lớn hơn phần thưởng và thực hiện các hành động sai sẽ dẫn đến việc khoản tiền gửi bị lấy đi (diễn giải của Vlad ở đây).

Chúng tôi đã dành phần lớn nửa cuối năm 2014 để cố gắng giải quyết "Cuộc tấn công tầm xa", trong đó kẻ tấn công có thể rút tiền gửi của họ khỏi chuỗi chính và tạo thành một chuỗi tấn công khác có nhiều chữ ký hơn. Bằng cách này, các nút mới tham gia sẽ bị lừa vào nghĩ rằng chuỗi tấn công là một chuỗi chính. Nếu điểm thời gian của chuỗi tấn công và nhánh chuỗi chính tương đối gần với thời điểm hiện tại, thì chuỗi tấn công sẽ không gây ra sự cố, bởi vì nếu người xác minh ký hai thông báo xung đột trên cả hai chuỗi cùng một lúc, chữ ký này có thể được sử dụng như một hình phạt đối với bằng chứng của người xác minh để tịch thu tiền ký quỹ; tuy nhiên, nếu fork xảy ra cách đây đã lâu (do đó có thuật ngữ tấn công từ xa), kẻ tấn công có thể rút tiền ký quỹ để tránh bị tịch thu.

Chúng tôi kết luận rằng các cuộc tấn công tầm xa là không thể tránh khỏi vì những lý do gần giống như những người đề xuất PoW nói. Tuy nhiên, chúng tôi không chấp nhận kết luận của họ. Bởi vì chúng tôi nhận thấy rằng chúng tôi có thể đưa ra hai giả định bảo mật bổ sung để giải quyết các cuộc tấn công từ xa: 1. Các nút phải đăng nhập ít nhất 4 tháng một lần (tiền gửi mất 4 tháng để rút ra);

Sau khi thiết lập việc sử dụng tiền gửi và tiền phạt, tiếp theo chúng ta cần quyết định chúng là gì. Chúng tôi biết rằng những gì chúng tôi muốn là "tính hữu hạn về mặt kinh tế" và những người xác thực sẽ ký các khối dựa trên phương pháp sau: sau khi một khối được hoàn thiện, nếu một khối xung đột sẽ được hoàn thiện, phần lớn những người xác thực phải ký Gửi các thông báo xung đột với tin nhắn trước đây của bạn. Nhưng đối với một tin nhắn như vậy, nó có thể bị chuỗi phát hiện và trừng phạt.

Casper CBC

Tôi đã viết một bài báo "Đồng thuận đặt cược" hôi thối, dài dòng và lạc đề. Đồng thuận đặt cược là một đề xuất thú vị: những người xác thực đặt cược vào khối nào sẽ được hoàn thiện và số tiền đặt cược sẽ xác định chuỗi nào sẽ đạt được sự đồng thuận. PoW cũng có thuộc tính này vì khai thác là một hoạt động đặt cược. Nếu bạn đặt cược vào đúng chuỗi, bạn sẽ nhận được phần thưởng; nếu bạn đặt cược vào chuỗi sai, bạn sẽ mất chi phí khai thác. Nhưng trong PoS, chúng ta có thể có tỷ lệ cược cao hơn: tỷ lệ cược của người xác thực bắt đầu thấp, nhưng khi người xác nhận thấy sự tin tưởng của nhau trong một khối tăng dần, tỷ lệ cược của mọi người tăng song song theo cấp số nhân , cho đến khi mọi người đặt cược vào cùng một khối, điều này được hoàn tất.

tiêu đề phụ

Đồng thời, Vlad bắt đầu thực hiện nhiều nghiên cứu về thiết kế cơ chế, đặc biệt là khiến Casper có khả năng chống độc quyền cao hơn. Chúng tôi cũng bắt đầu làm việc dựa trên sự đồng thuận lấy cảm hứng từ Dung sai lỗi Byzantine cổ điển (BFT), chẳng hạn như Tendermint. Vlad cho rằng BFT cổ điển không thuyết phục (anh ấy đặc biệt không thích ngưỡng cứng trong BFT, ví dụ: 2/3 nút PBFT phải là nút trung thực) và anh ấy muốn sử dụng cái mà anh ấy gọi là "Chỉnh sửa theo cách xây dựng (CBC)" Phương pháp này cố gắng phát minh lại BFT (từ gốc của Vlad: liên kết 1 / liên kết 2 / liên kết 3).

Để phát hiện tính hữu hạn, các nút tìm kiếm các mẫu trong thông báo. Những thông báo này có thể chứng minh rằng phần lớn những người xác thực đã bỏ phiếu một cách đáng tin cậy cho một số khối B theo một cách và việc sai lệch khỏi B yêu cầu phần lớn những người xác thực chuyển đổi phiếu bầu một cách bất hợp pháp. Ví dụ: nếu tất cả các nút đã bỏ phiếu cho B, thì tất cả các nút đã bỏ phiếu cho "khối chứa phiếu bầu của mọi người cho B", điều này chứng tỏ rằng họ ủng hộ B và biết rằng những người khác cũng ủng hộ B, vì vậy họ sẽ không có cơ sở pháp lý chuyển đổi.

Casper FFG

Cuối cùng, tôi đã từ bỏ việc đặt cược đồng thuận vì cách tiếp cận này về cơ bản có vẻ rủi ro. Tôi cũng đã quay lại và cố gắng tìm hiểu cách thức hoạt động của PBFT. Phải mất một thời gian, nhưng sau một vài tháng, tôi đã tìm ra nó.

tiêu đề phụ

Quá trình hoàn thiện là một bước phát triển rất quan trọng: một khi khối được hoàn thiện, nó có thể đảm bảo tính bảo mật cho dù mạng có trễ đến đâu (không giống như PoW, yêu cầu xác nhận nhiều khối) và khối quay lui yêu cầu hơn 1/3 số người xác minh gian lận , và có thể được phát hiện và tiền gửi bị phá hủy. Do đó, chi phí hoàn tất hồi tố có thể lên tới hàng trăm triệu đô la. Cả Casper CBC và FFG đều đạt được tính năng này theo những cách khác nhau.

FFG vs CBC

Cần lưu ý rằng cả Casper CBC và FFG đều là lớp phủ trừu tượng và cả hai đều cần được xây dựng dựa trên quy tắc lựa chọn ngã ba hiện có. Theo ngôn ngữ bản địa, Casper CBC sẽ hoàn thiện lớp bao phủ (lớp trên) để thích ứng với quy tắc chọn ngã ba (lớp dưới); trong khi Casper FFG sẽ điều chỉnh lớp phủ đã hoàn thiện (lớp trên) cho phù hợp với quy tắc chọn ngã ba (lớp dưới) ).

tiêu đề phụ

Sở thích ban đầu của Vlad đối với quy tắc lựa chọn rẽ nhánh là "GHOST dựa trên thông báo mới nhất (LMD GHOST)" - một phiên bản sửa đổi của GHOST cho PoS; và sở thích ban đầu của tôi là áp dụng "Hybrid PoS (PoS kết hợp) trước". sử dụng PoW làm quy tắc lựa chọn ngã ba cơ sở.

Trong phiên bản gốc của FFG, PoW sẽ chạy chuỗi khối theo từng khối và PoS sẽ theo sau để hoàn thiện khối; Casper CBC có đầy đủ PoS ngay từ đầu. Trong khi đó, Vlad và tôi từng đưa ra giả thuyết về các khuyến khích đồng thuận.

Một điểm khác biệt rất quan trọng ở đây là "Lỗi do nguyên nhân duy nhất" - bạn có thể biết ai là người chịu trách nhiệm khi xảy ra sự cố và bị trừng phạt, và "Lỗi do nguyên nhân không phải do nguyên nhân" - Lỗi có thể do một trong nhiều bên gây ra. Một trường hợp cổ điển của lỗi không thể quy cho duy nhất là ngoại tuyến so với che chắn (Kiểm duyệt), còn được gọi là "tương đương lỗi giữa người nói và người nghe". Không thể xác định đó là lỗi của ai).

Xử phạt các lỗi quy kết duy nhất (Casper FFG cắt giảm điều kiện tiền gửi) thì dễ; trừng phạt các lỗi quy kết không duy nhất thì khó. Điều gì sẽ xảy ra nếu bạn không thể biết liệu các khối ngừng được hoàn thiện do một số ít nút đã ngoại tuyến hay do phần lớn các nút đã chặn một thiểu số? Hiện tại có ba giải pháp cho vấn đề này: 1. Phạt nhẹ cả hai bên; 2. Phạt nặng cả hai bên (ưu tiên của Vlad); 3. Chia chuỗi thành hai, phạt một bên trong hai chuỗi và để thị trường quyết định bên nào Chuỗi có giá trị hơn (sở thích của tôi). Hoặc bạn có thể tham khảo bài viết này tôi đã viết.

Vào tháng 11 năm 2017, tôi đã cắt điều kiện gửi tiền của Casper FFG và nút 1/3 do "Rò rỉ bậc hai" Các giải pháp cho các vấn đề ngoại tuyến được viết thành giấy.

Tất nhiên, tôi nhận thức rất rõ rằng việc sử dụng các khía cạnh xã hội để giải quyết các cuộc tấn công 51% là không tốt lắm, vì vậy tôi bắt đầu tìm cách để ít nhất cho phép các nút trên chuỗi tự động phát hiện "chuỗi hợp pháp" và "chuỗi tấn công". Đây là một ý tưởng ban đầu. Đây là một ý tưởng hay, nhưng vẫn chưa tối ưu, trừ khi mạng không có độ trễ, nó chỉ có thể đảm bảo giới hạn trên về sự khác biệt về điểm nghi ngờ giữa các nút và không phải tất cả các nút đều hoàn toàn đồng ý.

Điều đáng nói là tất cả các vấn đề trên không chỉ xảy ra với PoS. Trên thực tế, trong PoW, mọi người có xu hướng bỏ cuộc và cho rằng việc ngăn chặn cuộc tấn công 51% là gần như không thể và cuộc tấn công 51% là ngày tận thế cần phải tránh bằng mọi giá. Tuy nhiên, như trường hợp của Ethereum, Vlad và tôi đã nhầm từ "tham vọng" với một lời khen và tiếp tục điều tra các cách khác nhau để giảm thiểu và phục hồi sau các cuộc tấn công 51%.

Đầu năm 2018, nghiên cứu của Vlad tại CBC bắt đầu tiến triển nhanh chóng, bao gồm cả tiến độ về bằng chứng an toàn. —Xem bản tóm tắt dài 2 giờ hoành tráng này để theo kịp tiến độ nghiên cứu cho đến hết tháng 3 năm 2018. Trong thời gian chờ đợi, Casper FFG cũng đã đạt được những tiến bộ đáng kể và quyết định triển khai nó theo hợp đồng giúp quá trình phát triển trở nên dễ dàng hơn. Vào ngày 31 tháng 12 năm 2017, chúng tôi đã phát hành phiên bản Python của mạng thử nghiệm.

tiêu đề phụ

Tích hợp Casper với lộ trình phát triển sharding

Thật không may, sự phát triển của FFG đã chậm lại. Mặc dù việc triển khai FFG với các hợp đồng giúp một số việc trở nên dễ dàng hơn, nhưng việc chuyển từ EVM sang EWASM và từ Casper chuỗi đơn sang Casper phân đoạn trong tương lai sẽ khó khăn hơn. Ngoài ra, công việc R&D của nhóm được chia thành "Main Chain Casper" và "Shard Chain Casper". Có thể hình dung rằng rất nhiều công việc trùng lặp không cần thiết đã xảy ra giữa hai nhóm này.

Vào tháng 6 năm 2018, chúng tôi đã đưa ra một quyết định quan trọng: từ bỏ Casper FFG, được thực hiện bằng hợp đồng, thay vào đó theo đuổi Casper, hoạt động như một chuỗi độc lập.

Việc chuyển sang PoS đầy đủ đã khiến tôi bắt đầu suy nghĩ nghiêm túc hơn về các quy tắc lựa chọn fork của PoS. Cả Casper FFG và CBC đều yêu cầu tất cả các nút xác minh bỏ phiếu trong mỗi "Kỷ nguyên" để hoàn thiện một khối, điều đó có nghĩa là hàng chục nghìn chữ ký được gửi đến mỗi nút xác minh mỗi giây. Tập hợp chữ ký BLS làm cho chi phí tính toán khả thi. Nhưng tôi muốn thử sử dụng các chữ ký bổ sung này để làm cho chuỗi ổn định hơn và đạt được mức bảo mật tương đương với "100 xác nhận" trong vài giây. Đây là những suy nghĩ ban đầu của tôi (liên kết 1/liên kết 2).

Tuy nhiên, tất cả các phương pháp lựa chọn fork này đều có một thiếu sót: tất cả chúng đều chia các nút xác minh thành "Người chứng thực" và "Người đề xuất" và những nhà sản xuất khối chịu trách nhiệm tạo khối này có quyền lực lớn. Điều này không tốt lắm, chủ yếu là vì nó yêu cầu chúng tôi phải có một trình tạo số ngẫu nhiên trên chuỗi rất an toàn để chọn ra các nút khối một cách công bằng và trình tạo số ngẫu nhiên trên chuỗi rất khó và một số phương pháp đơn giản như RANDAO dường như có Thêm và nhiều câu hỏi hơn nữa. Justin Drake và tôi bắt đầu giải quyết vấn đề này: Justin sử dụng VDF, một chức năng có đầu ra xác định và có thể kiểm chứng, nhưng yêu cầu một lượng lớn thời gian trình tự không song song để hoạt động, khiến việc can thiệp sớm là không thể; Vlad dạy cách thỏa hiệp, sử dụng GHOST dựa trên các quy tắc lựa chọn fork để giảm đáng kể sự phụ thuộc vào các nhà sản xuất khối, cho phép chuỗi phát triển không bị xáo trộn khi các nhà sản xuất khối độc hại lớn hơn 90% và các nút nhân chứng trung thực lớn hơn 50%. Vlad vui, nhưng không quá vui: anh ấy thích LMD GHOST hơn, còn tôi thích IMD GHOST hơn.

Đồng thời, tôi cũng đang cố gắng tìm ra cách "tạo đường ống" cho Casper FFG, giảm thời gian hoàn thiện từ 2,5 kỷ nguyên xuống mức tối ưu lý thuyết là 2 kỷ nguyên. Tôi rất vui vì quy tắc chọn ngã ba RPJ (sau này được đổi tên thành IMD GHOST) hoạt động tốt với FFG. Nó cũng có một "sự ổn định" rất quan trọng: lựa chọn fork là một dự đoán tốt cho các lựa chọn fork trong tương lai. Điều này có vẻ hiển nhiên, nhưng rất dễ tạo ra các quy tắc rẽ nhánh không có thuộc tính này. Tiến độ mới nhất là: LMD GHOST có thể chỉ có 25% error Resistant trong 2 Round do chi tiết kỹ thuật, nhưng IMD GHOST vẫn có thể có Full Error 33% (hiện chưa có tài liệu). (Dịch: Khi dịch xong Ethereum 2.0 dùng LMD GHOST)

Sự đánh đổi chính giữa FFG và CBC là: CBC dường như có các đặc tính lý thuyết tốt hơn; trong khi FFG có vẻ dễ thực hiện hơn. Đồng thời, VDF cũng đã có nhiều tiến bộ.