Giới thiệu

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Giống như khái niệm về một mật mã hoàn toàn mạnh từ mật mã, các giao thức “Đèn hiệu ngẫu nhiên có thể xác minh công khai” thực sự (sau đây gọi là PVRB) chỉ cố gắng tiến gần nhất có thể đến sơ đồ lý tưởng, bởi vì trong các mạng thực, nó không thể áp dụng ở dạng thuần túy: cần phải đồng ý nghiêm ngặt trên một bit, phải có nhiều vòng và tất cả các tin nhắn phải hoàn toàn nhanh chóng và luôn được gửi. Tất nhiên, đây không phải là trường hợp trong các mạng thực. Do đó, khi thiết kế PVRB cho các nhiệm vụ cụ thể trong các chuỗi khối hiện đại, ngoài việc không thể kiểm soát tính ngẫu nhiên và sức mạnh mật mã, còn phát sinh nhiều vấn đề về kiến ​​trúc và kỹ thuật thuần túy hơn.

Đối với PVRB, bản thân blockchain về cơ bản là một phương tiện truyền thông trong đó tin nhắn = giao dịch. Điều này cho phép bạn loại bỏ một phần các sự cố mạng, không gửi được tin nhắn, sự cố với phần mềm trung gian - tất cả những rủi ro này đều do mạng phi tập trung giả định và giá trị chính của nó đối với PVRB là không thể thu hồi hoặc làm hỏng giao dịch đã gửi - điều này không không cho phép người tham gia từ chối tham gia giao thức, trừ khi họ thực hiện một cuộc tấn công thành công vào sự đồng thuận. Mức độ bảo mật này có thể chấp nhận được, do đó PVRB phải có khả năng chống lại sự thông đồng của những người tham gia ở mức độ tương tự như chuỗi blockchain chính. Ngoài ra, điều này gợi ý rằng PVRB phải là một phần của sự đồng thuận nếu mạng đồng ý về blockchain chính, ngay cả khi nó cũng đồng ý về kết quả ngẫu nhiên công bằng duy nhất. Hoặc, PVRB đơn giản là một giao thức độc lập được triển khai bởi một hợp đồng thông minh hoạt động không đồng bộ đối với chuỗi khối và các khối. Cả hai phương pháp đều có ưu điểm và nhược điểm, và việc lựa chọn giữa chúng là vô cùng khó khăn.

Hai cách thực hiện PVRB

Hãy để chúng tôi mô tả chi tiết hơn hai tùy chọn để triển khai PVRB - phiên bản độc lập, hoạt động bằng cách sử dụng hợp đồng thông minh độc lập với blockchain và phiên bản tích hợp đồng thuận, được tích hợp trong giao thức, theo đó mạng đồng ý về blockchain và các giao dịch cần được đưa vào. Trong mọi trường hợp, ý tôi là các công cụ blockchain phổ biến: Ethereum, EOS và tất cả những công cụ tương tự với chúng về cách chúng lưu trữ và xử lý các hợp đồng thông minh.

Hợp đồng độc lập

Trong phiên bản này, PVRB là một hợp đồng thông minh chấp nhận giao dịch của các nhà sản xuất ngẫu nhiên (sau đây gọi là RP), xử lý chúng, kết hợp các kết quả và kết quả là đạt đến một giá trị nhất định mà bất kỳ người dùng nào cũng có thể nhận được từ hợp đồng này. Giá trị này có thể không được lưu trữ trực tiếp trong hợp đồng mà chỉ được thể hiện bằng dữ liệu từ đó có thể thu được một và chỉ một giá trị của kết quả ngẫu nhiên. Trong sơ đồ này, RP là người dùng blockchain và bất kỳ ai cũng có thể được phép tham gia vào quá trình tạo.

Tùy chọn với hợp đồng độc lập là tốt:

• tính di động (hợp đồng có thể được kéo từ blockchain này sang blockchain khác)
• dễ thực hiện và thử nghiệm (hợp đồng dễ viết và kiểm tra)
• thuận tiện trong việc thực hiện các kế hoạch kinh tế (dễ dàng tạo mã thông báo của riêng bạn, có logic phục vụ mục đích của PVRB)
• khả năng khởi chạy trên các chuỗi khối đã hoạt động

Nó cũng có nhược điểm:

• những hạn chế mạnh mẽ về tài nguyên máy tính, khối lượng giao dịch và dung lượng lưu trữ (nói cách khác là cpu/mem/io)
• hạn chế đối với các hoạt động trong hợp đồng (không phải tất cả các hướng dẫn đều có sẵn, rất khó kết nối các thư viện bên ngoài)
• không có khả năng tổ chức nhắn tin nhanh hơn các giao dịch được đưa vào blockchain

Tùy chọn này phù hợp để triển khai PVRB cần chạy trên mạng hiện có, không chứa mật mã phức tạp và không yêu cầu số lượng tương tác lớn.

Tích hợp đồng thuận

Trong phiên bản này, PVRB được triển khai trong mã nút blockchain, được tích hợp sẵn hoặc chạy song song với việc trao đổi tin nhắn giữa các nút blockchain. Kết quả của giao thức được ghi trực tiếp vào các khối được tạo và các thông báo giao thức được gửi qua mạng p2p giữa các nút. Vì giao thức dẫn đến các số được viết thành khối nên mạng phải đạt được sự đồng thuận về chúng. Điều này có nghĩa là các thông báo PVRB, giống như các giao dịch, phải được xác thực bởi các nút và được đưa vào các khối để bất kỳ người tham gia mạng nào cũng có thể xác thực việc tuân thủ giao thức PVRB. Điều này tự động dẫn chúng ta đến giải pháp rõ ràng - nếu mạng đồng ý về sự đồng thuận về một khối và các giao dịch trong đó, thì PVRB sẽ là một phần của sự đồng thuận chứ không phải là một giao thức độc lập. Mặt khác, có thể một khối có giá trị theo quan điểm đồng thuận, nhưng giao thức PVRB không được tuân theo và theo quan điểm của PVRB, khối đó không thể được chấp nhận. Vì vậy, nếu phương án “tích hợp đồng thuận” được chọn, PVRB sẽ trở thành một phần quan trọng của sự đồng thuận.

Khi mô tả việc triển khai PVRB ở cấp độ đồng thuận của mạng, người ta không thể tránh khỏi các vấn đề về tính hữu hạn. Tính cuối cùng là một cơ chế được sử dụng trong các sự đồng thuận mang tính quyết định nhằm khóa một khối (và chuỗi dẫn đến nó) là cuối cùng và sẽ không bao giờ bị bỏ đi, ngay cả khi xảy ra một nhánh song song. Ví dụ: trong Bitcoin không có cơ chế như vậy - nếu bạn xuất bản một chuỗi có độ phức tạp cao hơn, nó sẽ thay thế bất kỳ chuỗi nào ít phức tạp hơn, bất kể độ dài của chuỗi. Và ví dụ, trong EOS, khối cuối cùng được gọi là Khối không thể đảo ngược cuối cùng, xuất hiện trung bình cứ sau 432 khối (12*21 + 12*15, bỏ phiếu trước + cam kết trước). Quá trình này về cơ bản là chờ 2/3 chữ ký của nhà sản xuất khối (sau đây gọi là BP). Khi các nhánh xuất hiện cũ hơn LIB cuối cùng, chúng sẽ bị loại bỏ. Cơ chế này giúp đảm bảo rằng giao dịch được đưa vào blockchain và sẽ không bao giờ bị khôi phục, bất kể kẻ tấn công có tài nguyên gì. Ngoài ra, các khối cuối cùng là các khối được ký bởi 2/3 BP trong Hyperledger, Tendermint và các đồng thuận dựa trên pBFT khác. Ngoài ra, sẽ rất hợp lý khi tạo một giao thức để đảm bảo tính hữu hạn trở thành một tiện ích bổ sung cho sự đồng thuận, vì nó có thể hoạt động không đồng bộ với việc sản xuất và xuất bản các khối. Đây là một cái tốt bài viết về tính hữu hạn trong Ethereum.

Tính hữu hạn là cực kỳ quan trọng đối với người dùng, những người không có nó có thể thấy mình là nạn nhân của một cuộc tấn công “chi tiêu gấp đôi”, trong đó BP “giữ” các khối và xuất bản chúng sau khi mạng đã “thấy” một giao dịch tốt. Nếu không có kết quả cuối cùng, thì đợt phân nhánh đã xuất bản sẽ thay thế khối bằng một giao dịch “tốt” bằng một giao dịch khác, từ một đợt phân nhánh “xấu”, trong đó số tiền tương tự sẽ được chuyển đến địa chỉ của kẻ tấn công. Trong trường hợp của PVRB, các yêu cầu về tính hữu hạn thậm chí còn nghiêm ngặt hơn, vì việc xây dựng các nhánh cho PVRB có nghĩa là kẻ tấn công có cơ hội chuẩn bị một số tùy chọn ngẫu nhiên để xuất bản tùy chọn có lợi nhất và hạn chế thời gian của một cuộc tấn công có thể xảy ra là một giải pháp tốt.

Do đó, lựa chọn tốt nhất là kết hợp PVRB và tính hữu hạn vào một giao thức - sau đó khối cuối cùng = ngẫu nhiên cuối cùng và đây chính xác là những gì chúng ta cần có. Giờ đây, người chơi sẽ nhận được ngẫu nhiên được đảm bảo sau N giây và có thể chắc chắn rằng không thể quay lại hoặc phát lại lần nữa.

Tùy chọn tích hợp đồng thuận là tốt:

• khả năng triển khai không đồng bộ liên quan đến việc sản xuất khối - các khối được sản xuất như bình thường, nhưng song song với điều này, giao thức PVRB có thể hoạt động, không tạo ra tính ngẫu nhiên cho mọi khối
• khả năng triển khai thậm chí cả mật mã nặng mà không bị hạn chế đối với hợp đồng thông minh
• khả năng tổ chức trao đổi tin nhắn nhanh hơn các giao dịch được đưa vào blockchain, ví dụ: một phần của giao thức có thể hoạt động giữa các nút mà không cần phân phối tin nhắn qua mạng

Nó cũng có nhược điểm:

• Khó khăn trong quá trình thử nghiệm và phát triển - bạn sẽ phải mô phỏng các lỗi mạng, thiếu nút, phân nhánh mạng
• Lỗi triển khai yêu cầu hardfork mạng

Cả hai phương pháp triển khai PVRB đều có quyền tồn tại, nhưng việc triển khai hợp đồng thông minh trong các chuỗi khối hiện đại vẫn còn khá hạn chế về tài nguyên máy tính và bất kỳ sự chuyển đổi nào sang mật mã nghiêm túc thường đơn giản là không thể. Và chúng ta sẽ cần mật mã nghiêm túc, như sẽ được trình bày dưới đây. Mặc dù vấn đề này rõ ràng chỉ là tạm thời, nhưng cần có mật mã nghiêm túc trong hợp đồng để giải quyết nhiều vấn đề và nó đang dần xuất hiện (ví dụ: hợp đồng hệ thống cho zkSNARK trong Ethereum)

Blockchain, cung cấp kênh nhắn tin giao thức minh bạch và đáng tin cậy, không làm điều đó miễn phí. Bất kỳ giao thức phi tập trung nào cũng phải tính đến khả năng xảy ra tấn công Sybil; mọi hành động đều có thể được thực hiện bởi lực lượng phối hợp của nhiều tài khoản, do đó, khi thiết kế cần tính đến khả năng kẻ tấn công tạo ra số lượng giao thức tùy ý những người tham gia thông đồng.

PVRB và chặn các biến.

Tôi đã không nói dối khi nói rằng chưa có ai triển khai PVRB tốt, được thử nghiệm bởi nhiều ứng dụng cờ bạc trong chuỗi khối. Vậy thì rất nhiều ứng dụng cờ bạc trên Ethereum và EOS đến từ đâu? Điều này làm tôi ngạc nhiên cũng như làm bạn ngạc nhiên, họ lấy đâu ra nhiều ngẫu nhiên “liên tục” như vậy trong một môi trường hoàn toàn xác định?

Cách ưa thích để có được tính ngẫu nhiên trong blockchain là lấy một số loại thông tin “không thể đoán trước” từ khối và tạo một thông tin ngẫu nhiên dựa trên nó - chỉ bằng cách băm một hoặc nhiều giá trị. Bài viết hay về các vấn đề của các chương trình như vậy đây. Bạn có thể lấy bất kỳ giá trị “không thể đoán trước” nào trong khối, chẳng hạn như hàm băm khối, số lượng giao dịch, độ phức tạp của mạng và các giá trị khác chưa biết trước. Sau đó băm chúng, một hoặc nhiều, và theo lý thuyết, bạn sẽ nhận được một kết quả ngẫu nhiên thực sự. Bạn thậm chí có thể thêm vào wihitepaper rằng sơ đồ của bạn là “an toàn hậu lượng tử” (vì có các hàm băm chứng minh lượng tử :)).

Nhưng than ôi, ngay cả các hàm băm an toàn sau lượng tử cũng không đủ. Bí mật nằm ở những yêu cầu đối với PVRB, hãy để tôi nhắc bạn về chúng ở bài viết trước:

1. Kết quả phải có sự phân bố thống nhất có thể chứng minh được, tức là dựa trên mật mã mạnh có thể chứng minh được.
2. Không thể kiểm soát bất kỳ bit nào của kết quả. Kết quả là không thể đoán trước được kết quả.
3. Bạn không thể phá hoại giao thức tạo bằng cách không tham gia vào giao thức hoặc làm mạng quá tải với các thông báo tấn công
4. Tất cả những điều trên phải chống lại sự thông đồng của một số lượng người tham gia giao thức không trung thực cho phép (ví dụ: 1/3 số người tham gia).

Trong trường hợp này, chỉ đáp ứng yêu cầu 1 và không đáp ứng yêu cầu 2. Bằng cách băm các giá trị không thể đoán trước từ khối, chúng ta sẽ có được phân bố đồng đều và ngẫu nhiên tốt. Nhưng ít nhất BP cũng có tùy chọn “xuất bản khối hay không”. Do đó, BP ít nhất có thể chọn từ HAI tùy chọn ngẫu nhiên: “của riêng nó” và tùy chọn sẽ xuất hiện nếu có người khác tạo khối. BP có thể “rình mò” trước điều gì sẽ xảy ra nếu anh ta xuất bản một khối và chỉ cần quyết định có làm điều đó hay không. Do đó, khi chơi, chẳng hạn như “chẵn lẻ” hoặc “đỏ/đen” trong roulette, anh ta chỉ có thể xuất bản một khối nếu anh ta thấy thắng. Điều này cũng làm cho chiến lược sử dụng, chẳng hạn như khối băm “từ tương lai” không thể thực hiện được. Trong trường hợp này, họ nói rằng “ngẫu nhiên sẽ được sử dụng, dữ liệu này thu được bằng cách băm dữ liệu hiện tại và hàm băm của khối trong tương lai có chiều cao, chẳng hạn như N + 42, trong đó N là chiều cao khối hiện tại. Điều này củng cố kế hoạch này một chút, nhưng vẫn cho phép BP, mặc dù trong tương lai, lựa chọn giữ khối hay xuất bản.

Phần mềm BP trong trường hợp này trở nên phức tạp hơn nhưng không nhiều. Đơn giản, khi xác thực và đưa một giao dịch vào một khối, sẽ có một bước kiểm tra nhanh để xem liệu có chiến thắng hay không và có thể lựa chọn một tham số giao dịch để có xác suất thắng cao. Đồng thời, gần như không thể bắt được một BP thông minh cho những thao tác như vậy, mỗi lần bạn có thể sử dụng địa chỉ mới và giành chiến thắng từng chút một mà không gây nghi ngờ.

Vì vậy, các phương pháp sử dụng thông tin từ khối không phù hợp để triển khai PVRB một cách phổ biến. Trong phiên bản giới hạn, với các hạn chế về quy mô đặt cược, hạn chế về số lượng người chơi và/hoặc đăng ký KYC (để ngăn một người chơi sử dụng nhiều địa chỉ), các kế hoạch này có thể hoạt động cho các trò chơi nhỏ, nhưng không có gì hơn thế.

PVRB và cam kết tiết lộ.

Được rồi, nhờ có hàm băm và ít nhất là tính không thể đoán trước tương đối của hàm băm khối và các biến khác. Nếu bạn giải quyết được vấn đề về các công cụ khai thác chạy trước, bạn sẽ nhận được thứ gì đó phù hợp hơn. Hãy thêm người dùng vào kế hoạch này - hãy để họ cũng ảnh hưởng đến tính ngẫu nhiên: bất kỳ nhân viên hỗ trợ kỹ thuật nào cũng sẽ nói với bạn rằng điều ngẫu nhiên nhất trong hệ thống CNTT là hành động của người dùng :)

Một sơ đồ ngây thơ, khi người dùng chỉ cần gửi các số ngẫu nhiên và kết quả được tính toán, chẳng hạn như hàm băm của tổng của chúng, là không phù hợp. Trong trường hợp này, người chơi cuối cùng có thể, bằng cách chọn ngẫu nhiên của riêng mình, kiểm soát kết quả sẽ như thế nào. Đây là lý do tại sao mẫu tiết lộ cam kết được sử dụng rất rộng rãi được sử dụng. Trước tiên, những người tham gia gửi hàm băm từ ngẫu nhiên của họ (cam kết), sau đó tự mở ngẫu nhiên (tiết lộ). Giai đoạn “tiết lộ” chỉ bắt đầu sau khi các cam kết cần thiết đã được thu thập, vì vậy người tham gia có thể gửi chính xác hàm băm ngẫu nhiên mà họ đã gửi trước đó. Bây giờ, hãy đặt tất cả những thứ này cùng với các tham số của một khối và tốt hơn là một khối được lấy từ tương lai (tính ngẫu nhiên chỉ có thể được tìm thấy ở một trong các khối trong tương lai) và thì đấy - tính ngẫu nhiên đã sẵn sàng! Giờ đây, bất kỳ người chơi nào cũng có thể tác động đến tính ngẫu nhiên thu được và có thể “đánh bại” BP độc hại bằng cách ghi đè nó bằng tính ngẫu nhiên, không xác định trước của chính mình... Bạn cũng có thể thêm tính năng bảo vệ chống phá hoại giao thức bằng cách không mở nó ở giai đoạn tiết lộ - chỉ đơn giản là bằng cách yêu cầu một số tiền nhất định được đính kèm vào giao dịch khi thực hiện - một khoản tiền đặt cọc, số tiền này sẽ chỉ được trả lại trong quá trình tiết lộ. Trong trường hợp này, cam kết mà không tiết lộ sẽ không có lợi.

Đó là một nỗ lực tốt và những kế hoạch như vậy cũng tồn tại trong DApp chơi game, nhưng than ôi, điều này một lần nữa là chưa đủ. Giờ đây, không chỉ người khai thác mà bất kỳ người tham gia giao thức nào cũng có thể ảnh hưởng đến kết quả. Vẫn có thể tự kiểm soát giá trị, với ít biến đổi hơn và tốn kém hơn, nhưng, như trong trường hợp của người khai thác, nếu kết quả rút thăm có giá trị hơn phí tham gia giao thức PVRB, thì ngẫu nhiên -producer(RP) có thể quyết định có tiết lộ hay không và vẫn có thể chọn từ ít nhất hai tùy chọn ngẫu nhiên.
Nhưng có thể trừng phạt những người phạm tội và không tiết lộ, và kế hoạch này sẽ có ích. Tính đơn giản của nó là một lợi thế thực sự - các giao thức nghiêm túc hơn đòi hỏi khả năng tính toán mạnh mẽ hơn nhiều.

PVRB và chữ ký xác định.

Có một cách khác để buộc RP cung cấp số giả ngẫu nhiên mà nó không thể ảnh hưởng nếu được cung cấp “tiền ảnh” - đây là chữ ký xác định. Ví dụ: chữ ký như vậy là RSA chứ không phải là ECS. Nếu RP có một cặp khóa: RSA và ECC, và anh ta ký một giá trị nhất định bằng khóa riêng của mình, thì trong trường hợp RSA, anh ta sẽ nhận được MỘT VÀ CHỈ MỘT chữ ký, và trong trường hợp ECS, anh ta có thể tạo ra bất kỳ số lượng chữ ký nào. chữ ký hợp lệ khác nhau. Điều này là do khi tạo chữ ký ECS, một số ngẫu nhiên được sử dụng, do người ký chọn và số đó có thể được chọn theo bất kỳ cách nào, giúp người ký có cơ hội chọn một trong nhiều chữ ký. Trong trường hợp RSA: “một giá trị đầu vào” + “một cặp khóa” = “một chữ ký”. Không thể dự đoán chữ ký mà RP khác sẽ nhận được là gì, do đó, một PVRB có chữ ký xác định có thể được tổ chức bằng cách kết hợp chữ ký RSA của một số người tham gia đã ký cùng một giá trị. Ví dụ, ngẫu nhiên trước đó. Sơ đồ này tiết kiệm rất nhiều tài nguyên, bởi vì chữ ký vừa là xác nhận hành vi đúng theo giao thức vừa là nguồn ngẫu nhiên.

Tuy nhiên, ngay cả với các chữ ký xác định, sơ đồ vẫn dễ bị ảnh hưởng bởi vấn đề “tác nhân cuối cùng”. Người tham gia cuối cùng vẫn có thể quyết định có công bố chữ ký hay không, từ đó kiểm soát kết quả. Bạn có thể sửa đổi sơ đồ, thêm băm khối vào nó, thực hiện các vòng để không thể dự đoán trước kết quả, nhưng tất cả các kỹ thuật này, ngay cả khi tính đến nhiều sửa đổi, vẫn chưa giải quyết được vấn đề về ảnh hưởng của một người tham gia đối với tập thể. dẫn đến một môi trường không đáng tin cậy và chỉ có thể hoạt động trong điều kiện hạn chế về kinh tế và thời gian. Ngoài ra, kích thước của khóa RSA (1024 và 2048 bit) khá lớn và kích thước cho các giao dịch blockchain là một tham số cực kỳ quan trọng. Có vẻ như không có cách nào đơn giản để giải quyết vấn đề, hãy tiếp tục.

PVRB và các chương trình chia sẻ bí mật

Trong mật mã, có những sơ đồ có thể cho phép mạng đồng ý về một và chỉ một giá trị PVRB, trong khi những sơ đồ đó có khả năng chống lại mọi hành động độc hại của một số người tham gia. Một giao thức hữu ích đáng để bạn làm quen là sơ đồ chia sẻ bí mật của Shamir. Nó dùng để chia một bí mật (ví dụ: khóa bí mật) thành nhiều phần và phân phối những phần này cho N người tham gia. Bí mật được phân phối sao cho M phần trong số N đủ để khôi phục nó và đây có thể là M phần bất kỳ. Nếu trên ngón tay, sau đó có biểu đồ của một hàm chưa xác định, những người tham gia trao đổi điểm trên biểu đồ và sau khi nhận được M điểm, toàn bộ hàm có thể được khôi phục.
Một lời giải thích tốt được đưa ra trong wiki nhưng việc chơi với nó một cách thực tế để chơi giao thức trong đầu bạn sẽ rất hữu ích cho bản demo trang.

Nếu kế hoạch FSSS (Chia sẻ bí mật Fiat-Shamir) được áp dụng ở dạng thuần túy, thì đó sẽ là một PVRB không thể phá hủy. Ở dạng đơn giản nhất, giao thức có thể trông như thế này:

• Mỗi người tham gia tạo ngẫu nhiên của riêng mình và phân phối cổ phần từ đó cho những người tham gia khác
• Mỗi người tham gia tiết lộ phần bí mật của mình về những người tham gia khác
• Nếu một người tham gia có nhiều hơn M lượt chia sẻ thì số lượng người tham gia này có thể được tính toán và nó sẽ là duy nhất, bất kể nhóm người tham gia được tiết lộ
• Sự kết hợp ngẫu nhiên được tiết lộ là PVRB mong muốn

Ở đây, một cá nhân tham gia không còn ảnh hưởng đến kết quả của giao thức, ngoại trừ trường hợp việc đạt được ngưỡng tiết lộ ngẫu nhiên chỉ phụ thuộc vào anh ta. Do đó, giao thức này, nếu có một tỷ lệ RP cần thiết hoạt động trên giao thức và có sẵn, sẽ hoạt động, thực hiện các yêu cầu về độ mạnh mật mã và có khả năng chống lại vấn đề “tác nhân cuối cùng”.

Đây có thể là một lựa chọn lý tưởng, sơ đồ PVRB dựa trên việc chia sẻ bí mật Fiat-Shamir này được mô tả chẳng hạn trong điều này bài báo. Tuy nhiên, như đã đề cập ở trên, nếu bạn cố gắng áp dụng nó trực tiếp vào blockchain, các hạn chế về mặt kỹ thuật sẽ xuất hiện. Dưới đây là ví dụ về việc triển khai thử nghiệm giao thức trong hợp đồng thông minh EOS và phần quan trọng nhất của nó - kiểm tra người tham gia chia sẻ đã xuất bản: mã. Bạn có thể thấy từ đoạn mã rằng việc xác thực bằng chứng yêu cầu một số phép nhân vô hướng và các số được sử dụng rất lớn. Cần hiểu rằng trong blockchain, việc xác minh xảy ra tại thời điểm nhà sản xuất khối xử lý giao dịch và nói chung, bất kỳ người tham gia nào cũng phải dễ dàng xác minh tính chính xác của giao thức, do đó yêu cầu về tốc độ của chức năng xác minh là rất nghiêm trọng. . Trong tùy chọn này, tùy chọn hóa ra không hiệu quả vì xác minh không nằm trong giới hạn giao dịch (0.5 giây).

Nói chung, hiệu quả xác minh là một trong những yêu cầu quan trọng nhất đối với việc sử dụng bất kỳ sơ đồ mã hóa tiên tiến nào trong chuỗi khối. Tạo bằng chứng, chuẩn bị thông báo - các quy trình này có thể được thực hiện ngoài chuỗi và được thực hiện trên các máy tính hiệu suất cao, nhưng không thể bỏ qua việc xác minh - đây là một yêu cầu quan trọng khác đối với PVRB.

Chữ ký PVRB và ngưỡng

Sau khi làm quen với sơ đồ chia sẻ bí mật, chúng tôi phát hiện ra cả một lớp giao thức được thống nhất bởi từ khóa “ngưỡng”. Khi việc tiết lộ một số thông tin yêu cầu sự tham gia của M người tham gia trung thực trong số N và tập hợp những người tham gia trung thực có thể là tập con tùy ý của N, chúng ta nói đến sơ đồ “ngưỡng”. Chính họ là người cho phép chúng ta giải quyết vấn đề “diễn viên cuối cùng”, bây giờ nếu kẻ tấn công không tiết lộ phần bí mật của mình thì một người tham gia trung thực khác sẽ làm điều đó cho anh ta. Các kế hoạch này cho phép thỏa thuận về một và chỉ một ý nghĩa, ngay cả khi giao thức bị một số người tham gia phá hoại.

Sự kết hợp giữa chữ ký xác định và sơ đồ ngưỡng giúp phát triển một sơ đồ rất thuận tiện và đầy hứa hẹn để triển khai PVRB - đây là những chữ ký ngưỡng xác định. Đây bài viết về các cách sử dụng khác nhau của chữ ký ngưỡng và đây là một cách hay khác longread từ Dash.

Bài viết cuối cùng mô tả chữ ký BLS (BLS là viết tắt của Boneh-Lynn-Shacham, đây bài viết), có chất lượng rất quan trọng và cực kỳ thuận tiện cho các lập trình viên - khóa công khai, bí mật, khóa chung và chữ ký BLS có thể được kết hợp với nhau bằng các phép toán đơn giản, trong khi sự kết hợp của chúng vẫn giữ nguyên các khóa và chữ ký hợp lệ, cho phép bạn dễ dàng tổng hợp nhiều chữ ký thành một và nhiều khóa công khai thành một. Chúng cũng mang tính quyết định và tạo ra cùng một kết quả cho cùng một dữ liệu đầu vào. Nhờ chất lượng này, bản thân các tổ hợp chữ ký BLS là các khóa hợp lệ, cho phép thực hiện tùy chọn trong đó M trong số N người tham gia tạo ra một và chỉ một chữ ký có tính xác định, có thể xác minh công khai và không thể đoán trước cho đến khi nó được mở bởi Mth. người tham gia .

Trong sơ đồ có chữ ký BLS ngưỡng, mỗi người tham gia ký một cái gì đó bằng cách sử dụng BLS (ví dụ: ngẫu nhiên trước đó) và chữ ký ngưỡng chung là ngẫu nhiên mong muốn. Các thuộc tính mật mã của chữ ký BLS đáp ứng các yêu cầu về chất lượng ngẫu nhiên, phần ngưỡng bảo vệ chống lại “tác nhân cuối cùng” và khả năng kết hợp duy nhất của các khóa giúp có thể triển khai nhiều thuật toán thú vị hơn, chẳng hạn như cho phép tổng hợp hiệu quả các thông điệp giao thức .

Vì vậy, nếu bạn đang xây dựng PVRB trên blockchain của mình, rất có thể bạn sẽ kết thúc với sơ đồ chữ ký ngưỡng BLS, một số dự án đã sử dụng nó. Ví dụ: Dfinity (đây điểm chuẩn thực hiện mạch và đây ví dụ về triển khai chia sẻ bí mật có thể kiểm chứng) hoặc Keep.network (đây là đèn hiệu ngẫu nhiên của họ giấy vàngNhưng Ví dụ hợp đồng thông minh phục vụ giao thức).

Triển khai PVRB

Thật không may, chúng tôi vẫn chưa thấy một giao thức làm sẵn nào được triển khai trong chuỗi khối PVRB đã chứng minh được tính bảo mật và ổn định của nó. Mặc dù bản thân các giao thức đã sẵn sàng nhưng việc áp dụng chúng về mặt kỹ thuật vào các giải pháp hiện có không hề dễ dàng. Đối với các hệ thống tập trung, PVRB không có ý nghĩa và các hệ thống phi tập trung bị hạn chế nghiêm ngặt về tất cả các tài nguyên tính toán: CPU, bộ nhớ, bộ lưu trữ, I/O. Thiết kế PVRB là sự kết hợp của các giao thức khác nhau để tạo ra thứ gì đó đáp ứng tất cả các yêu cầu cho ít nhất một số blockchain khả thi. Một giao thức tính toán hiệu quả hơn nhưng yêu cầu nhiều tin nhắn hơn giữa các RP, trong khi giao thức kia yêu cầu rất ít tin nhắn, nhưng việc tạo bằng chứng có thể là một công việc mất hàng chục phút hoặc thậm chí hàng giờ.

Tôi sẽ liệt kê các yếu tố bạn sẽ phải cân nhắc khi chọn PVRB chất lượng:

• Sức mạnh mật mã. PVRB của bạn phải hoàn toàn không thiên vị, không có khả năng kiểm soát một bit nào. Trong một số chương trình, điều này không xảy ra, vì vậy hãy gọi cho chuyên gia mật mã
• Vấn đề “diễn viên cuối cùng”. PVRB của bạn phải có khả năng chống lại các cuộc tấn công trong đó kẻ tấn công kiểm soát một hoặc nhiều RP có thể chọn một trong hai kết quả.
• Vấn đề phá hoại giao thức. PVRB của bạn phải có khả năng chống lại các cuộc tấn công trong đó kẻ tấn công kiểm soát một hoặc nhiều RP quyết định có ngẫu nhiên hay không và có thể được đảm bảo hoặc có xác suất nhất định để ảnh hưởng đến điều này
• Vấn đề về số lượng tin nhắn. RP của bạn nên gửi tối thiểu tin nhắn tới blockchain và tránh các hành động đồng bộ càng nhiều càng tốt, chẳng hạn như các tình huống như “Tôi đã gửi một số thông tin, tôi đang chờ phản hồi từ một người tham gia cụ thể”. Trong mạng p2p, đặc biệt là các mạng phân tán về mặt địa lý, bạn không nên mong đợi phản hồi nhanh chóng
• Vấn đề về độ phức tạp tính toán. Việc xác minh bất kỳ giai đoạn nào của PVRB trên chuỗi phải cực kỳ dễ dàng vì nó được thực hiện bởi tất cả các khách hàng đầy đủ của mạng. Nếu việc triển khai được thực hiện bằng hợp đồng thông minh thì yêu cầu về tốc độ rất nghiêm ngặt
• Vấn đề về khả năng tiếp cận và sự sống động. PVRB của bạn nên cố gắng có khả năng phục hồi trong các tình huống trong đó một phần của mạng không khả dụng trong một khoảng thời gian và một phần của RP ngừng hoạt động
• Vấn đề về thiết lập đáng tin cậy và phân phối khóa ban đầu. Nếu PVRB của bạn sử dụng thiết lập chính của giao thức thì đây là một câu chuyện lớn và nghiêm trọng. Đây Ví dụ. Nếu những người tham gia phải cho nhau biết khóa của họ trước khi bắt đầu giao thức, đây cũng là một vấn đề nếu thành phần của những người tham gia thay đổi
• Vấn đề phát triển. Tính sẵn có của các thư viện bằng các ngôn ngữ được yêu cầu, tính bảo mật và hiệu suất, tính công khai, các bài kiểm tra phức tạp, v.v.

Ví dụ: chữ ký ngưỡng BLS có một vấn đề nghiêm trọng - trước khi bắt đầu làm việc, những người tham gia phải phân phối khóa cho nhau, tổ chức một nhóm trong ngưỡng đó sẽ hoạt động. Điều này có nghĩa là ít nhất một vòng trao đổi trong mạng phi tập trung sẽ phải chờ và chẳng hạn, do đồng rand được tạo ra là cần thiết trong các trò chơi, gần như trong thời gian thực, điều này có nghĩa là việc phá hoại giao thức có thể xảy ra ở giai đoạn này , và lợi ích của sơ đồ ngưỡng bị mất đi . Vấn đề này vốn đã đơn giản hơn những vấn đề trước, nhưng vẫn đòi hỏi phải xây dựng một quy trình riêng để hình thành các nhóm ngưỡng, nhóm này sẽ phải được bảo vệ về mặt kinh tế, thông qua việc gửi và rút tiền (chém) từ những người tham gia không tuân theo quy định. giao thức. Ngoài ra, việc xác minh BLS với mức độ bảo mật có thể chấp nhận được đơn giản là không phù hợp, chẳng hạn như với giao dịch EOS hoặc Ethereum tiêu chuẩn - đơn giản là không có đủ thời gian để xác minh. Mã hợp đồng là WebAssugging hoặc EVM, được thực thi bởi máy ảo. Các chức năng mật mã chưa được triển khai nguyên bản và hoạt động chậm hơn hàng chục lần so với các thư viện mật mã thông thường. Nhiều giao thức không đáp ứng các yêu cầu chỉ dựa trên khối lượng khóa, ví dụ 1024 và 2048 bit cho RSA, lớn hơn 4-8 lần so với chữ ký giao dịch tiêu chuẩn trong Bitcoin và Ethereum.

Sự hiện diện của việc triển khai bằng các ngôn ngữ lập trình khác nhau cũng đóng một vai trò nào đó - trong số đó có rất ít, đặc biệt là đối với các giao thức mới. Tùy chọn tích hợp vào sự đồng thuận yêu cầu viết giao thức bằng ngôn ngữ nền tảng, vì vậy bạn sẽ phải tìm mã trong Go for geth, trong Rust for Parity, trong C++ cho EOS. Mọi người sẽ phải tìm kiếm mã JavaScript và vì JavaScript và mật mã không phải là bạn bè đặc biệt thân thiết nên WebAssugging sẽ trợ giúp, điều này hiện chắc chắn được coi là tiêu chuẩn Internet quan trọng tiếp theo.

Kết luận

Tôi hy vọng ở phần trước Bài viết Tôi đã thuyết phục được bạn rằng việc tạo số ngẫu nhiên trên blockchain là rất quan trọng đối với nhiều khía cạnh trong hoạt động của mạng phi tập trung và với bài viết này, tôi đã chỉ ra rằng nhiệm vụ này cực kỳ tham vọng và khó khăn, nhưng đã có những giải pháp tốt. Nói chung, thiết kế cuối cùng của giao thức chỉ có thể thực hiện được sau khi tiến hành các thử nghiệm lớn có tính đến tất cả các khía cạnh từ thiết lập đến mô phỏng lỗi, do đó, bạn khó có thể tìm thấy các công thức làm sẵn trong các bài báo và báo cáo nghiên cứu chuyên sâu của nhóm và chúng tôi chắc chắn sẽ không quyết định trong một hoặc hai năm tới hãy viết “làm theo cách này, hoàn toàn đúng.”

Tạm biệt, vì PVRB của chúng tôi trong blockchain đang được phát triển Haya, chúng tôi đã quyết định sử dụng chữ ký ngưỡng BLS, chúng tôi dự định triển khai PVRB ở cấp độ đồng thuận, vì vẫn chưa thể xác minh trong hợp đồng thông minh với mức độ bảo mật có thể chấp nhận được. Có thể chúng tôi sử dụng hai sơ đồ cùng một lúc: thứ nhất, chia sẻ bí mật đắt tiền để tạo Random_seed dài hạn, sau đó chúng tôi sử dụng nó làm cơ sở cho việc tạo ngẫu nhiên tần số cao bằng cách sử dụng chữ ký BLS ngưỡng xác định, có lẽ chúng tôi sẽ chỉ giới hạn ở mức một trong những phương án Thật không may, không thể nói trước giao thức sẽ như thế nào; điều tốt duy nhất là, giống như trong khoa học, trong các vấn đề kỹ thuật, một kết quả tiêu cực cũng là một kết quả, và mỗi nỗ lực mới để giải quyết vấn đề là một bước tiến khác cho nghiên cứu của tất cả những người liên quan đến vấn đề này. Để đáp ứng các yêu cầu kinh doanh, chúng tôi giải quyết một vấn đề thực tế cụ thể - cung cấp cho các ứng dụng trò chơi một nguồn entropy đáng tin cậy, vì vậy chúng tôi cũng phải chú ý đến chính blockchain, đặc biệt là các vấn đề về tính hữu hạn của chuỗi và quản trị mạng.

Và mặc dù chúng tôi chưa thấy PVRB có khả năng kháng cự đã được chứng minh trong các chuỗi khối, nó đã được sử dụng trong thời gian đủ để được kiểm tra bởi các ứng dụng thực, nhiều lần kiểm tra, tải và tất nhiên là các cuộc tấn công thực, nhưng số lượng đường dẫn có thể xác nhận rằng một giải pháp tồn tại và những thuật toán nào cuối cùng sẽ giải quyết được vấn đề. Chúng tôi sẽ vui lòng chia sẻ kết quả và cảm ơn các nhóm khác cũng đang giải quyết vấn đề này vì các bài viết và mã cho phép các kỹ sư không dẫm lên cùng một cái cào hai lần.

Vì vậy, khi bạn gặp một lập trình viên thiết kế ngẫu nhiên phi tập trung, hãy chú ý và quan tâm, đồng thời trợ giúp tâm lý nếu cần thiết :)

Nguồn: www.habr.com