Bài phát biểu mới nhất của Vitalik: PoW đối phó với cuộc tấn công 51% như thế nào? PoS có phải là lối thoát?

Giờ Bắc Kinh từ ngày 20 đến ngày 22 tháng 2, Hội nghị Blockchain Stanford 2020 do Findora tổ chức đã được tổ chức tại Đại học Stanford. Hội nghị này tập trung vào các phương pháp quản lý rủi ro và kỹ thuật bảo mật blockchain trong hệ thống khám phá cách cải thiện tính bảo mật của hệ thống blockchain thông qua ứng dụng công nghệ mã hóa, giao thức phi tập trung, phương pháp chính thức và phân tích thực nghiệm.

Vào ngày thứ hai của hội nghị, người đồng sáng lập Ethereum Vitalik Buterin đã có bài phát biểu với tiêu đề "Vượt xa cuộc tấn công 51%". Trong hội nghị, lần đầu tiên ông đề cập đến các kiểu tấn công 51% khác nhau, chẳng hạn như The cuộc tấn công giao dịch khôi phục phổ biến nhất, ngoài các cuộc tấn công kiểm duyệt, tấn công khách hàng nhẹ, tấn công can ngăn và tấn công trại sinh sản nghiêm trọng nhất, ông tin rằng tiền điện tử bằng chứng công việc (PoW) dễ bị tổn thương bởi những tác động này. Tiền điện tử -of-Stake (PoS) có thể phát hiện chuỗi tấn công và xem xét các cuộc tấn công thông qua các công nghệ như đồng thuận có khả năng chịu lỗi 99% và phát hiện kịp thời (TD), từ đó loại bỏ mối đe dọa do các cuộc tấn công 51% gây ra.

Tấn công 51% có thể làm được gì? Có nhiều loại tấn công 51% khác nhau, có thể thực hiện các hành động khác nhau trên các ứng dụng khác nhau và tạo ra các kết quả cũng như hậu quả khác nhau. Một đòn tấn công 51% mà bạn có thể quen thuộc là đẩy lùi các khối. Bạn thực hiện một giao dịch, gửi tiền đến một sàn giao dịch, đổi số tiền đó lấy một đồng tiền khác, bạn rút tiền và sau đó thực hiện cuộc tấn công 51% để khôi phục giao dịch tiền gửi của mình...

Đây là kiểu tấn công 51% chính mà chúng tôi đã thảo luận trong 10 năm qua và cũng là kiểu mà chúng tôi nghĩ đến nhiều nhất.

1. Các kiểu tấn công 51% khác

Tấn công đánh giá giao dịch 1, 1

Trên thực tế, việc xem xét giao dịch là một cuộc tấn công 51% khác! Do các giao thức lớp 2 và DeFi đều là những xu hướng lớn gần đây nên việc kiểm duyệt giao dịch đã trở nên đặc biệt nguy hiểm. Trong bối cảnh có nhiều giao thức lớp 2 (bao gồm plasma, kênh, kênh trạng thái chung, Lightning Network, Optimistic Rollup, điện toán tương tác, TruBit, v.v.), kiểm duyệt có nghĩa là trộm cắp!
Vì vậy, nếu bạn có thể kiểm duyệt các giao dịch thách thức, bạn có thể ăn cắp tiền từ mọi người. Điều này không hoạt động trên zk Rollup, nhưng cuộc tấn công này hoạt động trên phần lớn các giao thức mà mọi người đang xem xét hiện nay. Trong bối cảnh DeFi, kiểm duyệt đặc biệt nguy hiểm vì đây là công cụ mà qua đó bạn có thể thao túng thị trường và sau đó thu được giá trị.

Nếu bạn có thể xem xét mọi giao dịch chuỗi khối Ethereum chạm vào Uniswap và sau đó đợi một ngày, giá Ethereum có thể sẽ tăng cao một chút biến động, và tôi sẽ có thể thu được nhiều giá trị chênh lệch giá từ cuộc tấn công này.

Có thể nói rằng kiểm duyệt là nguy hiểm và trong các giao thức DeFi và giao thức lớp 2, kiểm duyệt giao dịch cũng có thể được coi là ngang bằng với trộm cắp .

1, 2 cuộc tấn công nhẹ vào máy khách

Nhiều người đang chạy ứng dụng khách nhẹ và nếu bạn đang chạy ứng dụng khách nhẹ, một cuộc tấn công 51% có thể khiến các ứng dụng khách nhẹ này chấp nhận chuỗi chứa các khối giao dịch hoàn toàn không hợp lệ. Chữ ký xấu, giao dịch không đúng định dạng, chữ ký trái phép (đánh cắp tiền từ một tài khoản và chuyển chúng sang tài khoản khác), chúng có thể nhận được các khối có thể sử dụng được mạng lưới chấp nhận.

Tấn công 1, 3 dữ liệu không có sẵn

Ở đây có ai quen với các vấn đề về tính khả dụng của dữ liệu? Chà, không phải tất cả mọi người, nhưng rất nhiều người đã hiểu được. Ý tưởng ở đây là bạn tạo một chuỗi nơi tiêu đề khối được xuất bản. Các máy khách nhẹ có thể nhìn thấy chuỗi nhưng không thể xuất bản một số hoặc tất cả dữ liệu trong thân khối. Lý do điều này tệ là vì nếu dữ liệu không được công bố thì nó có thể đúng hoặc không chính xác và không có cách nào để tạo ra bằng chứng để chứng minh cho người khác rằng dữ liệu đó có thể đúng và bạn phủ nhận mọi người khả năng tạo các giao dịch trong tương lai. Thông tin. Nói cách khác, các khối không có sẵn cũng nguy hiểm.

1, 4 ngăn chặn các cuộc tấn công

Tấn công nản lòng là thuật ngữ dùng để chỉ việc gây tổn hại ác ý cho những người tham gia khác, khiến họ mất thu nhập và khiến họ thông đồng với bạn. Hoặc buộc phải nghỉ việc . Khai thác ích kỷ với hơn 1/3 sức mạnh tính toán là một ví dụ như vậy. Điều đó nói lên rằng, cuộc tấn công 51% cũng là một cuộc tấn công can ngăn rất mạnh mẽ.

1, 5 Về tính bất biến của blockchain Sex

Vì vậy, cuộc tấn công 51% rất mạnh mẽ. Kiểu tấn công này rất có hại cho blockchain là mối đe dọa đối với tính bất biến của
Ai còn nhớ cái này không? Một sàn giao dịch đã bị đánh cắp một loạt tiền và họ đang xem xét việc đảo ngược chuỗi khối Bitcoin trong một ngày để lấy lại tiền. Nếu điều đó có thể xảy ra thì những thứ bên trong blockchain có thể được khôi phục và blockchain sẽ mất đi các thuộc tính quan trọng của nó khi là một blockchain, điều này thật đáng sợ.

Ngoài ra, 51% các cuộc tấn công là không dân chủ, chúng là chế độ tài phiệt, vì vậy, là một phương pháp dân chủ, đối với họ điều đó chẳng có gì tốt đẹp cả Nó.

2,51% cuộc tấn công đã xảy ra trên thực tế và 51% trường hợp tấn công tồi tệ nhất

span>

Trên thực tế, một cuộc tấn công 51% có thể được thực hiện. Đây là bức ảnh từ Quy mô Bitcoin Hồng Kông năm 2015 Hội nghị. Trong bức ảnh này, một số người kiểm soát 90% sức mạnh tính toán của Bitcoin ngồi cùng nhau và tạo dáng như “Tôi có sức mạnh”, haha.

Có thể hoàn thành 51% các cuộc tấn công. Ví dụ: ETC, Bitcoin Gold, v.v. đều đã phải hứng chịu các cuộc tấn công 51%. Tôi chắc chắn Tôi đã bỏ lỡ 1-2, những cuộc tấn công này đã xảy ra rồi.

Tấn công trại sinh sản

Thực tế là các cuộc tấn công 51% mà chúng ta đang chứng kiến cho đến nay không phải là cuộc tấn công tồi tệ nhất. Một cuộc tấn công vào trại sinh sản là kịch bản ác mộng tồi tệ nhất đối với kiểu tấn công này. Về cơ bản, bạn cần có đủ phần cứng để tấn công một chuỗi, đợi nó phục hồi rồi tấn công lại vì bạn vẫn còn phần cứng. Cuối cùng, cộng đồng sẽ chán ngấy với sự tra tấn này và họ sẽ thay đổi thuật toán Proof of Work (PoW), vì họ sẽ không thể xây dựng ASIC trong một thời gian ngắn nên bạn sẽ chỉ cần thuê rất nhiều sức mạnh tính toán của CPU và GPU để tiếp tục cuộc tấn công, và sau đó, Chuỗi này sẽ chết trừ khi họ chuyển sang Proof of Stake (PoS) hoặc trở thành thứ gì đó hoàn toàn tập trung.

3. Liệu thuật toán Proof of Stake (PoS) có thể phá vỡ chu trình này không?

Đây là một bài đăng trên blog tôi viết vào năm 2016, nơi tôi đã cố gắng mô tả triết lý đằng sau Bằng chứng cổ phần (PoS) là gì và Tại sao đây là thứ chúng ta mong đợi tồn tại và tại sao nó lại là một thứ có ý nghĩa. Có sự bất đối xứng trong Proof of Stake (PoS), khác với Proof of Work (PoW), là bạn chỉ có phần thưởng nên bị phạt khi tham gia tấn công hoặc không tham gia tấn công, chỉ có phần thưởng khối . Trong hệ thống bằng chứng cổ phần (PoS), cuộc tấn công của bạn có thể bị phát hiện và số tiền gửi bạn mất lớn hơn nhiều so với số tiền gửi có thể bị mất.

Chúng được đưa vào Casper CBC và một loạt thuật toán bằng chứng cổ phần (PoS) khác dựa trên tiền gửi an toàn và cắt giảm. Về lý thuyết, mục tiêu của thiết kế này là khiến cuộc tấn công 51% trở nên cực kỳ tốn kém. Về cơ bản, bạn muốn tấn công một chuỗi PoS, bạn cần phải mua một đống coin, bạn cần kiểm soát trên 50% số coin trong hệ thống, và khi đó khi bị bắt quả tang đang cố gắng tấn công, bạn sẽ phải chịu một hình phạt, nếu bạn muốn làm lại. Để phát động một cuộc tấn công, bạn phải mua nhiều xu hơn vì bạn tiếp tục mua, và khi đó giá xu tăng cao cuối cùng sẽ khiến bạn phá sản. Vì vậy, từ góc độ này, thay vì để những kẻ tấn công nhắm vào PoW, Mục tiêu của chúng tôi là để chuỗi chuyển sang PoS.

Còn các kiểu tấn công khác thì sao?

Bây giờ chúng ta hãy thảo luận về câu hỏi đầu tiên, PoS giải quyết các loại tấn công khác như thế nào? Cho đến nay, chúng tôi đã xem xét sự đảo chiều cuối cùng. Điều này khá phổ biến trong lý thuyết đồng thuận chịu lỗi của Byzantine. Ý tưởng cơ bản là nếu 2/3 số bên đứng về một bên và 1/3 bên còn lại đứng về phía bên kia... 1/3 số người xác nhận phải gửi hai tin nhắn xung đột và bạn có thể phát hiện và trừng phạt họ . Tuy nhiên, đây là về việc đảo ngược cuộc tấn công.

Còn các kiểu tấn công khác thì sao? Dữ liệu không hợp lệ, không có sẵn dữ liệu, kiểm duyệt và phá hoại?

Hãy giải quyết từng chút một, chúng tôi sẽ không quan tâm đến tính hợp lệ của dữ liệu, chúng tôi sẽ lưu ý rằng nếu Bạn có sự đảm bảo về tính khả dụng của dữ liệu và sự đảm bảo rằng nếu một khối là một phần của chuỗi khối thì tất cả dữ liệu trong khối đó có thể được tải xuống bởi một nút trong mạng. Nếu bạn gặp phải sự phản đối kiểm duyệt và bạn xuất bản một khối thì cuối cùng nó sẽ được đưa vào, và từ hai điều đó, bạn sẽ có được tính hợp lệ. Lý do là tính toán tương tác, tổng hợp và các giao thức hiện có này. Về cơ bản, với Rollup, bạn xuất bản tất cả dữ liệu trên chuỗi và sau đó chuỗi đảm bảo tính khả dụng của nó, bạn có một số bằng chứng gian lận và đảm bảo rằng nếu một số tính toán không hợp lệ thì bạn có thể xuất bản bằng chứng gian lận không thể kiểm tra được và xử lý nó trên chuỗi . . Vì vậy, tính hợp lệ của dữ liệu không quan trọng vì bằng chứng gian lận lớp 1 và lớp 2 có thể giải quyết vấn đề này.

Nếu bạn không thể kiểm duyệt các khối của người khác thì bạn không thể ngăn việc đưa chúng vào chuỗi khối. Vì vậy, chỉ cần các hình phạt khuyến khích được kiểm soát hiệu quả thì việc mài giũa sẽ không phải là vấn đề lớn.

Chúng ta có thể tóm gọn lại thành hai vấn đề: tấn công vào tính khả dụng của dữ liệu và tấn công kiểm duyệt.

Dữ liệu không hợp lệ và không có dữ liệu

Đây là bài báo tôi đồng viết với musalbas và cộng sự vào năm 2017, trong đó tôi mô tả một phương pháp về cơ bản cho phép các máy khách blockchain không thực sự tải xuống tất cả dữ liệu. Trong trường hợp này, một giải pháp để xác minh tính sẵn có của dữ liệu blockchain.

Một phiên bản đơn giản của giải pháp này là: cách ngu ngốc nhất để kiểm tra xem một khối có sẵn hay không là tải xuống những điều hoàn chỉnh. Nhưng ở đây, chúng tôi giả định một blockchain có khả năng mở rộng, có thể phân chia, trong đó hơn 2 MB/giây dữ liệu sẽ được tải lên chuỗi và khách hàng sẽ không thể tải xuống mọi thứ. Đối với khách hàng muốn kiểm tra tính sẵn có của dữ liệu, tất cả những gì chúng tôi phải làm là lấy mẫu thử nghiệm ngẫu nhiên. Nó sẽ chọn ngẫu nhiên một số đoạn dữ liệu, chẳng hạn như 30 đoạn, 40 đoạn, 80 đoạn... Nó sẽ chọn ngẫu nhiên các vị trí và yêu cầu bằng chứng merkle về các vị trí này. Miễn là bạn nhận được câu trả lời hợp lệ cho tất cả các vị trí mà bạn chấp nhận, thì Bạn sẽ chấp nhận khối là hợp lệ.

Nếu bạn chấp nhận một khối bằng cách sử dụng lược đồ này thì có thể bạn biết rằng khối đó hợp lệ. Nếu có ít hơn 50% dữ liệu, chẳng hạn như tất cả dữ liệu ở bên trái ở đây đều có, tất cả dữ liệu ở bên phải ở đây đều có, thì khả năng cao là ít nhất một trong các lần kiểm tra sẽ thất bại.

Thông qua kế hoạch này, kẻ tấn công có thể đánh lừa một số lượng nhỏ khách hàng cụ thể. Tuy nhiên, nếu kẻ tấn công giả mạo đủ số máy khách để chúng tải xuống một nửa dữ liệu lá mầm thì những máy khách đó có thể tiếp tục xây dựng lại dữ liệu từ đó.

Điều này không chứng tỏ rằng khối này có sẵn đầy đủ, nó có thể thiếu một phần, nhưng nó chứng tỏ rằng ít nhất một nửa khối có sẵn Nó có sẵn. Sẽ thật tuyệt nếu chúng ta có công nghệ nào đó có thể khôi phục toàn bộ khối dữ liệu từ 50% dữ liệu.

Xóa mã hóa

Đây là lúc mã hóa xóa xuất hiện, vì vậy chúng ta sẽ lấy dữ liệu và giả sử đó là một đánh giá đa thức và chúng ta sẽ đánh giá nó ở nhiều điểm hơn Đánh giá cùng một đa thức ở trên, bây giờ bất kỳ 50% dữ liệu nào cũng đủ để khôi phục tất cả dữ liệu. Với giải pháp này, bạn có thể xác minh rằng các khối này hữu ích và các khối có thể có kích thước rất lớn trong khi các cá nhân tải xuống 20-200 KB dữ liệu.
Đây là phần đầu tiên. Điều này bao gồm các cuộc tấn công vào tính khả dụng của dữ liệu, là một phần của giải pháp phân mảnh Ethereum 2.0, ít nhất cho phép chúng tôi cung cấp cho các chuỗi khối phân mảnh những đảm bảo về tính khả dụng tương tự.

Chứng minh tính đúng đắn

Làm thế nào để chứng minh rằng gốc là gốc của mã hóa xóa này? Làm thế nào để bạn chứng minh rằng bạn không có dữ liệu rác bị kẹt trong đó? Bạn có thể sử dụng bằng chứng gian lận, như bằng chứng 2D này, và nếu bạn mã hóa sai, thì ai đó có thể tạo bằng chứng gian lận ngắn và bạn có thể phát nó lên mạng và sau đó mạng có thể từ chối việc chặn. Công việc phát triển giải pháp 2D này bắt đầu vào năm 2017. Gần đây có một số nội dung về mã hóa cây merkle, trong đó bạn mã hóa từng cấp độ trong cây merkle, có các đặc tính hay. Ngoài ra còn có các phương pháp không dựa vào bằng chứng gian lận, chẳng hạn như sử dụng STARK hoặc SNARK để chứng minh rằng phép tính căn bậc merkle là chính xác, trong khi một khả năng khác liên quan đến cam kết đa thức - bạn sẽ nhận được dữ liệu của mình và bạn sẽ hiểu nó là đa thức Để đánh giá , bạn sẽ tìm ra đa thức và sau đó bạn đang thực hiện một loạt các lần mở được cam kết đa thức tại một loạt điểm và việc kiểm tra tính khả dụng của dữ liệu của bạn sẽ là yêu cầu 80 vị trí thay vì 80 lần mở hoặc nếu Bạn sử dụng đại số thông minh để có được một số kiểu mở đa dạng và bạn có thể đạt được hiệu quả cao hơn nữa.

Lợi ích của các kế hoạch này là chúng không dựa vào bằng chứng gian lận, do đó các kế hoạch được sử dụng để xác minh dữ liệu khối đã được xuất bản, chúng không còn có bất kỳ giả định bổ sung nào về độ trễ tích hợp nữa.

Sharding: Beyond Commission

Các chuỗi khối phân mảnh hiện đang tồn tại thường dựa vào các ủy ban. Ý tưởng là bạn có nhiều nút, bạn chọn ngẫu nhiên một số nút và bạn A Phần lớn hoặc phần lớn các nút này được yêu cầu đăng nhập vào một khối để mạng chấp nhận khối đó là hợp lệ.
Vấn đề là bất kỳ kế hoạch nào dựa trên ủy ban sẽ bị những kẻ xấu trên một ngưỡng nhất định xem xét kỹ lưỡng. Nếu chúng ta đang nói về khả năng chống lại các cuộc tấn công 51%, thì chúng ta đang nói về một hệ thống mà ngay cả khi đa số bắt đầu cuộc tấn công thì thiểu số vẫn có thể tiếp tục tự vận hành hệ thống.

Giải pháp phân chia ngưỡng cố định không thể thực sự giúp ích cho bạn. Vì vậy, giải pháp ở đây là giao thức cần dựa hoàn toàn vào một tập hợp các chương trình kiểm tra tính sẵn có của dữ liệu thay vì dựa vào các ủy ban.

Giới thiệu về bài đánh giá

Mọi người ở đây có ai muốn ngăn chặn kiểm duyệt không? Được rồi, có rất nhiều người, hiện trạng cũng không tốt lắm. Đây là bài viết của nrryuya, người đã thực hiện một số công việc về xác minh chính thức của Ethereum và anh ấy đã viết một bài báo nói rằng trong thiết kế hiện tại của Ethereum 2.0, có một số chiến lược có thể cho phép đa số mọi người xem xét các khối, Sự kiểm duyệt này không thể phân biệt được với sự chậm trễ của một khối, gây khó khăn cho việc xác định ai chịu trách nhiệm.

Cuộc tấn công ở đây khá ác ý, kẻ tấn công tấn công một số trình xác nhận và làm cho chúng hợp lệ cho một khối khác. người xác thực bỏ phiếu cho khối riêng của họ thực sự chứa nội dung cần xem xét... nhưng số phiếu bầu của chính họ không đủ để đạt được trên 51%, vì vậy những gì họ đang cố gắng xem xét sẽ thực sự không bao giờ được đưa vào. Đây là tác động gián tiếp ở nhiều cấp độ. Trong Ethereum 1.0 và Ethereum 2.0, một bên độc hại thực hiện cuộc tấn công 51% có thể tạo ra sự kiểm duyệt và khi sự kiểm duyệt đủ mạnh, sẽ rất khó để xác định liệu có cần phải làm gì đó hay không.

Đưa vào khối chú

Đây là điều cơ bản nhất mà chúng tôi có thể làm vào lúc này: bao gồm các khối chú. Ý tưởng ở đây là trong Ethereum 1.0, các khối không phải là một phần của blockchain có thể được đưa vào sau, trong khi với cách tiếp cận mới, chúng tôi đã thêm các quy tắc giao thức cho biết các giao dịch trong khối chú cũng sẽ được đưa vào xử lý.
Vậy là bạn có một chuỗi khối như vậy, trong đó bao gồm các khối chú.

Ý tưởng: Trình phát hiện tính kịp thời (TD)

Hãy tưởng tượng nếu ít nhất chúng ta có thể có khách hàng trực tuyến để khách hàng trên mạng có thể tải xuống nội dung và liên lạc thường xuyên với khách hàng khác . Hãy để họ kiểm tra xem họ có thấy khối nào đến đúng giờ không.
Nếu họ thấy một khối nào đó đến đúng giờ và họ thấy rằng khối đó chưa có. Nếu liên kết được chấp nhận, khối đó sẽ tự động bị loại. Nếu một khối không đến đúng giờ thì bạn có thể sử dụng nó để thực hiện cuộc tấn công khôi phục 51%.

Ý tưởng là khách hàng phát hiện cục bộ xem một khối nhất định có đến khi nó đến hay không và gửi nó. Được sử dụng làm thông tin để xác định chuỗi để theo đuổi.

Không phải mọi nút đều có thể tuân theo giao thức vì các nút ngoại tuyến cũng sẽ tồn tại. Trừ khi một cuộc tấn công 51% đang diễn ra, blockchain chiến thắng sẽ là một chuỗi tốt nếu không có cuộc tấn công nào xảy ra, nếu một cuộc tấn công xảy ra và bạn ngoại tuyến thì bạn gần như phải kiểm tra lớp xã hội để xem điều gì đang xảy ra, nhưng chỉ một số ít người tham gia sẽ làm như vậy và sẽ có sự đồng thuận khá rõ ràng giữa những người khác.

Vấn đề: Tấn công biên

Nếu bạn tạo một khối đến đúng giờ bất kể định nghĩa của khối đó như thế nào, một số nút sẽ thấy khối đó đến vào một thời điểm khác. Do đó, các nút có thể không thống nhất về việc liệu một khối có được xem xét quá lâu hay không và liệu khối đó có được xuất bản đúng thời hạn hay không.
Kẻ tấn công có thể lợi dụng điều này để gây ra những bất đồng lâu dài giữa những người khác về việc liệu cuộc tấn công có xảy ra hay không và gây ra nhiều vấn đề về quản trị. .

Vì vậy, điều này đòi hỏi chúng ta phải có một công cụ phát hiện tính kịp thời (TD) tốt hơn

Trình phát hiện kịp thời (TD) được cải tiến

Chúng tôi quay trở lại Bài toán các vị tướng Byzantine, bài báo năm 1982 của Leslie Lamport. Hóa ra bài báo có chứa một thuật toán mà mọi người không thực sự nói đến, nhưng có lẽ họ nên nói về nó nhiều hơn. Nó che giấu câu này một cách trừu tượng bằng một thông điệp bằng văn bản không thể giả mạo (được gọi là chữ ký điện tử). Lambert tuyên bố rằng ông có một thuật toán đồng thuận có thể chấp nhận tới 99% những kẻ tấn công sai lầm (tức là đồng thuận chấp nhận lỗi 99%).
Thuật toán này hiệu quả và ưu điểm của nó là nó có thể hoạt động miễn là bạn có các giả định về tính đồng bộ, không chỉ đối với những người khai thác đang thực hiện đồng thuận và người xác thực, mà còn giữa người khai thác và khách hàng cũng như giữa khách hàng và khách hàng khác. Nó đưa ra một giả định mạnh mẽ hơn về việc ai sẽ trực tuyến và nó sử dụng giả định này để đạt được mức độ chấp nhận lỗi cao hơn, nhưng đó là một giả định rất nguy hiểm mà chúng ta không sẵn sàng tự mình đưa ra.

Tôi sẽ mô tả phiên bản chứng minh duy nhất. Ở đây, giả sử rằng một người chứng minh là trung thực và có tổng cộng n người chứng minh, chúng ta chỉ cần 1/n người chứng minh là trung thực.

Ý tưởng ở đây là giả sử một khối được xuất bản thì khách hàng và người chứng minh sẽ có thời hạn mà họ cần phải chặn được nhận trước để khối được xem xét đúng thời hạn. Đối với khách hàng, thời hạn là t và đối với người chứng minh, thời hạn là t+δ. Vì vậy, người đề xuất ở đây sẽ xuất bản khối b, và giả sử người đề xuất hơi xấu xa và cố gắng thực hiện một cuộc tấn công biên trong đó nút 1 nhìn thấy nó trước thời hạn và nút 2 nhìn thấy nó trước thời hạn. Người hoạt động gửi khối, nhưng do giả định về tính đồng bộ của mạng, nếu một nút chấp nhận khối, thì điều này có nghĩa là người hoạt động được đảm bảo chấp nhận khối trước thời hạn của họ, vì khối có thể được gửi đến người hoạt động. Nếu thậm chí một khách hàng cho rằng một khối là kịp thời thì người chứng minh được đảm bảo sẽ xem nó trước thời hạn của họ, do đó, người chứng minh sẽ thêm chữ ký của riêng họ và do tính đồng bộ của mạng, khách hàng khác sẽ thấy chữ ký được thêm vào khối trước khi nó hết hạn ngày.

Cách mở rộng điều này cho nhiều người chứng minh rất đơn giản, bạn có nhiều người chứng minh, khách hàng sẽ là t+δ *k. Tôi có một bài viết trên eth.research dành riêng cho khía cạnh nghiên cứu này, vì vậy vui lòng xem qua nếu bạn muốn biết thêm chi tiết. Để đưa ra một ý tưởng sơ bộ, bạn có một nhóm kẻ tấn công, mỗi kẻ tấn công có thể trì hoãn thời hạn một chút, vì vậy nếu kẻ tấn công nhận được một khối, miễn là độ trễ mạng thấp hơn tham số delta của bạn, thì nó sẽ tính kịp thời của một khối được truyền tới phần còn lại của mạng.

Sự thật thú vị

Nếu có trình phát hiện tính kịp thời này, bạn sẽ xử lý tất cả các khối kịp thời theo thứ tự thời gian tự khai báo, thế là xong. Vấn đề duy nhất là nó yêu cầu thời gian chặn dài, đây có thể là một giao thức thú vị nếu bạn muốn xử lý việc gửi, rút tiền và cắt giảm của trình xác thực, nhưng đó không phải là giao thức tốt nhất để chạy blockchain.
Nói đúng hơn là bạn có thể sử dụng trình phát hiện tính kịp thời để phát hiện chuỗi tấn công và kiểm tra các cuộc tấn công.

4. Tóm tắt

Kỹ thuật chống kiểm duyệt không hoàn hảo như các kỹ thuật khác vì nó dựa vào các giả định đồng bộ hóa giữa mạng và máy khách. Bạn có thể đặt thời lượng này thành bất kỳ lúc nào bạn muốn, nhưng nó sẽ khác với thời lượng bạn muốn. sẵn sàng chịu đựng Tùy thuộc vào mức độ xem xét. Bạn có thể đảm bảo tính nhất quán giữa các nhóm nút trực tuyến và trong trường hợp xảy ra một cuộc tấn công, bạn có thể thống nhất xem một chuỗi có phải là chuỗi tấn công hay không và mọi thứ khác. Bạn có thể sử dụng điều này làm điểm khởi đầu cho sự đồng thuận xã hội một phần để xác định cách khôi phục, giúp bạn ấn định mức độ trừng phạt mạnh hơn cho kẻ tấn công vì bạn có thể xác định kẻ tấn công là ai một cách đáng tin cậy hơn.

Nói chung, nếu kẻ tấn công xuất bản một chuỗi không có sẵn thì việc kiểm tra tính khả dụng của dữ liệu sẽ phát hiện được chuỗi đó nếu nó xuất bản Khối không hợp lệ, thì bằng chứng gian lận có thể bắt được và nếu bạn xem xét khối trong thời gian dài thì chuỗi sẽ tự động bị mạng bỏ qua. Nếu bạn xem xét một khối thời gian trung bình, thì bạn có thể sử dụng trình phát hiện kịp thời để xử lý nó một cách rõ ràng và nếu kẻ tấn công đang cố gắng không tham gia hoặc phá hủy ủy ban thì ủy ban sẽ không được sử dụng tương ứng.

Chà, chúng tôi có một loạt công cụ về cơ bản có thể làm giảm đáng kể nỗi sợ hãi của chúng ta về các cuộc tấn công 51% hoặc có thể bỏ qua chúng, hoặc phục hồi từ chúng. cảm ơn tất cả.

Liên kết nguồn: https://www.8btc.com/article/558562

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