Sách trắng Bài viết Hình ảnh Thuật ngữ đồ thị Tìm kiếm

Chainlink: 分散型 Oracle ネットワーク

Tác giả Steve Ellis, Ari Juels and Sergey Nazarov · 2017

Chế độ một trang chain.link
🇺🇸 English (Bản gốc)
🇯🇵 日本語 (Bản dịch)

Tóm tắt

Trong báo cáo chính thức này, chúng tôi trình bày rõ tầm nhìn về sự phát triển của Chainlink ngoài quan niệm ban đầu trong báo cáo chính thức Chainlink ban đầu. Chúng tôi thấy trước vai trò ngày càng mở rộng của oracle mạng, một vai trò trong đó chúng bổ sung và nâng cao blockchain hiện có và mới bằng cách cung cấp tốc độ nhanh, đáng tin cậy và kết nối phổ quát và tính toán ngoài chuỗi đảm bảo tính bảo mật cho smart contracts. Nền tảng kế hoạch của chúng tôi là cái mà chúng tôi gọi là Mạng Oracle phi tập trung, hoặc Viết tắt là DONs. DON là mạng được duy trì bởi ủy ban Chainlink nút. Nó hỗ trợ bất kỳ chức năng oracle nào được chọn cho triển khai của ủy ban. Do đó DON hoạt động như một lớp trừu tượng mạnh mẽ, cung cấp giao diện cho smart contract cho các tài nguyên ngoài chuỗi mở rộng và có chất lượng cao tài nguyên điện toán ngoài chuỗi hiệu quả nhưng được phân cấp trong chính DON. Với DON làm bàn đạp, Chainlink có kế hoạch tập trung vào những tiến bộ trong bảy lĩnh vực chính: • smart contract kết hợp: Cung cấp một khuôn khổ chung, mạnh mẽ để tăng cường các khả năng smart contract hiện có bằng cách soạn thảo an toàn trên chuỗi và tài nguyên điện toán ngoài chuỗi thành cái mà chúng tôi gọi là smart contract lai. • Loại bỏ sự phức tạp: Trình bày cho các nhà phát triển và người dùng những cách đơn giản chức năng loại bỏ sự cần thiết phải làm quen với cơ bản phức tạp các giao thức và ranh giới hệ thống. • Mở rộng quy mô: Đảm bảo rằng các dịch vụ oracle đạt được độ trễ và thông lượng được yêu cầu bởi các hệ thống phi tập trung hiệu suất cao. • Tính bảo mật: Kích hoạt các hệ thống thế hệ tiếp theo kết hợp blockchains' tính minh bạch vốn có với các biện pháp bảo vệ bí mật mới mạnh mẽ cho các thông tin nhạy cảm dữ liệu. • Tính công bằng trong giao dịch: Hỗ trợ sắp xếp trình tự giao dịch theo cách công bằng cho người dùng cuối và ngăn chặn các cuộc tấn công chạy trước và các cuộc tấn công khác bằng cách bot và thợ mỏ bóc lột. • Giảm thiểu sự tin cậy: Tạo ra một lớp hỗ trợ có độ tin cậy cao cho smart contracts và các hệ thống phụ thuộc oracle khác bằng phương pháp phân cấp, neo chặt ở mức độ bảo mật cao blockchains, mật mã kỹ thuật và đảm bảo kinh tế mật mã. • Bảo mật dựa trên khuyến khích (kinh tế tiền điện tử): Các cơ chế thiết kế nghiêm ngặt và triển khai mạnh mẽ nhằm đảm bảo các nút trong DON có động lực kinh tế mạnh mẽ để hành xử một cách đáng tin cậy và chính xác, ngay cả khi đối mặt với các đối thủ có nguồn lực tốt. Chúng tôi giới thiệu những cải tiến sơ bộ và đang diễn ra của cộng đồng Chainlink trong mỗi lĩnh vực này, cung cấp một bức tranh về sự mở rộng và ngày càng tăng các khả năng mạnh mẽ được lên kế hoạch cho mạng Chainlink.

概要

このホワイトペーパーでは、元の Chainlink ホワイトペーパーの初期概念を超えた Chainlink の進化のビジョンを明確に示します。 私たちは予測します oracle ネットワークの役割はますます拡大しており、高速性、信頼性、信頼性を提供することで既存および新規の blockchain を補完および強化します。 機密性を維持したユニバーサル接続とオフチェーン計算 smart contract秒。 私たちの計画の基礎となるのは、分散型 Oracle ネットワーク (つまり分散型 Oracle ネットワーク) と呼ばれるものです。 略してDONs。 DON は、Chainlink の委員会によって維持されるネットワークです。 ノード。 目的に選択された無制限の範囲の oracle 関数をサポートします。 委員会による展開。したがって、DON は強力な抽象化レイヤーとして機能します。 smart contracts のインターフェイスを広範なオフチェーン リソースに提供し、 DON 自体内の効率的でありながら分散化されたオフチェーン コンピューティング リソース。 DON を出発点として、Chainlink は 7 つの分野の進歩に注力する予定です 主要分野: • ハイブリッド smart contracts: オンチェーンで安全に構成することで、既存の smart contract 機能を強化するための強力な一般的なフレームワークを提供します。 そして、オフチェーン コンピューティング リソースをハイブリッド smart contract と呼ぶものにします。 • 複雑さを抽象化する: 開発者とユーザーにシンプルなものを提供します。 この機能により、複雑な基盤に精通する必要がなくなります。 プロトコルとシステム境界。 • スケーリング: oracle サービスがレイテンシとスループットを達成できるようにする 高性能の分散システムによって要求されます。 • 機密性: blockchains を組み合わせた次世代システムの実現 本質的な透明性と、機密性の高い新しい強力な機密保護保護 データ。 • トランザクションの注文の公平性: トランザクションの順序付けをさまざまな方法でサポート これはエンドユーザーにとって公平であり、フロントランニング攻撃やその他の攻撃を防ぎます。 ボットと搾取的なマイナー。 • 信頼の最小化: 信頼性の高いサポート層を作成します。 smart contracts およびその他の oracle に依存するシステムは、分散化、高セキュリティ blockchains での強力なアンカーリング、暗号化によるものです。 技術と暗号経済的保証。 • インセンティブベースの (暗号経済) セキュリティ: DON のノードが、十分なリソースを備えた敵に直面しても確実かつ正しく動作するための強力な経済的インセンティブを確保するメカニズムを厳密に設計し、堅牢に展開します。 Chainlink コミュニティによる暫定的および進行中のイノベーションを紹介します これらの各分野で、拡大し、ますます拡大している状況の全体像を提供します。 Chainlink ネットワーク向けに計画されている強力な機能。

Giới thiệu

Conceptual figure showing how a Decentralized Oracle Network can realize basic oracle functionality by relaying off-chain data to a contract

Blockchain oracle ngày nay thường được xem là dịch vụ phi tập trung với một mục tiêu: để chuyển tiếp dữ liệu từ các tài nguyên ngoài chuỗi tới blockchains. Tuy nhiên, đó là một bước ngắn, từ chuyển tiếp dữ liệu đến tính toán, lưu trữ hoặc truyền dữ liệu hai chiều. Quan sát này biện minh cho khái niệm rộng hơn nhiều về chức năng của oracles. Vì vậy, quá thực hiện các yêu cầu dịch vụ ngày càng tăng của smart contract và ngày càng đa dạng công nghệ dựa trên mạng oracle. Tóm lại, oracle có thể và sẽ cần là một giao diện có mục đích chung, hai chiều, hỗ trợ tính toán giữa và giữa các hệ thống trên chuỗi và ngoài chuỗi. Vai trò của Oracles trong hệ sinh thái blockchain là nâng cao hiệu suất, chức năng và khả năng tương tác của smart contract để chúng có thể mang lại các mô hình tin cậy mới và tính minh bạch cho nhiều ngành công nghiệp. Sự chuyển đổi này sẽ diễn ra thông qua việc mở rộng việc sử dụng smart contract kết hợp, hợp nhất Thuộc tính đặc biệt của blockchains với khả năng độc đáo của các hệ thống ngoài chuỗi chẳng hạn như oracle mạng và do đó đạt được phạm vi tiếp cận và sức mạnh lớn hơn nhiều so với các hệ thống trên chuỗi trong sự cô lập. Trong sách trắng này, chúng tôi trình bày rõ tầm nhìn về cái mà chúng tôi gọi là Chainlink 2.0, một sự phát triển của Chainlink ngoài quan niệm ban đầu trong sách trắng ban đầu Chainlink [98]. Chúng tôi thấy trước vai trò ngày càng mở rộng của các mạng oracle, trong đó chúng bổ sung và nâng cao blockchain hiện có và mới bằng cách cung cấp kết nối và tính toán phổ quát nhanh chóng, đáng tin cậy và bảo mật cho kết hợp smart contracts. Chúng tôi tin rằng oracle mạng thậm chí sẽ phát triển để trở thành tiện ích để xuất dữ liệu cấp blockchain có tính toàn vẹn cao sang các hệ thống ngoài blockchain hệ sinh thái. Ngày nay, các nút Chainlink do một nhóm thực thể đa dạng điều hành kết hợp với nhau trong các mạng oracle để chuyển tiếp dữ liệu tới smart contract trong cái được gọi là báo cáo. Chúng ta có thể xem như vậy oracle nút như một ủy ban tương tự như ủy ban trong sự đồng thuận cổ điển blockchain [72], nhưng với mục tiêu hỗ trợ blockchain hiện có thay vì cung cấp chức năng độc lập. Với các chức năng ngẫu nhiên có thể xác minh (VRF) và Báo cáo Off-Chain (OCR), Chainlink đã phát triển theo hướng khung và cơ sở hạ tầng có mục đích chung để cung cấp tài nguyên tính toán mà smart contract yêu cầu cho chức năng nâng cao. Nền tảng kế hoạch của chúng tôi cho Chainlink 2.0 là cái mà chúng tôi gọi là Oracle phi tập trung Mạng hoặc gọi tắt là DON. Kể từ khi chúng tôi giới thiệu thuật ngữ “oracle mạng” trong bản gốc Chainlink sách trắng [98], oracle đã phát triển chức năng phong phú hơn bao giờ hết và bề rộng của ứng dụng. Trong bài viết này, chúng tôi đưa ra một định nghĩa mới cho thuật ngữ này theo tới tầm nhìn tương lai của chúng tôi về hệ sinh thái Chainlink. Trong chế độ xem này, DON là một mạng được duy trì bởi một ủy ban gồm Chainlink nút. Bắt nguồn từ một giao thức đồng thuận, nó hỗ trợ bất kỳ chức năng oracle nào trong phạm vi không giới hạn được chọn để triển khai bởi ủy ban. Do đó, DON hoạt động như một lớp trừu tượng blockchain, cung cấp giao diện tới các tài nguyên ngoài chuỗi cho cả smart contract và các hệ thống khác. Nó cũng cung cấp truy cập vào các tài nguyên điện toán ngoài chuỗi phi tập trung nhưng hiệu quả cao. Nói chung, a DON hỗ trợ các hoạt động trên chuỗi chính. Mục tiêu của nó là cho phép an toàn và linh hoạtble lai smart contracts, kết hợp tính toán trên chuỗi và ngoài chuỗi với kết nối với các tài nguyên bên ngoài. Chúng tôi nhấn mạnh rằng ngay cả khi sử dụng ủy ban trong DONs, chính Chainlink vốn dĩ vẫn không được phép. DON đóng vai trò là nền tảng của quyền không cần cấp phép khung trong đó các nút có thể kết hợp với nhau để triển khai các mạng oracle tùy chỉnh với chế độ riêng của họ để bao gồm nút, có thể được phép hoặc không được phép. Với DON làm nền tảng, chúng tôi dự định tập trung vào Chainlink 2.0 dựa trên những tiến bộ trong bảy các lĩnh vực chính: smart contract kết hợp, loại bỏ sự phức tạp, mở rộng quy mô, tính bảo mật, tính công bằng trong trật tự cho các giao dịch, giảm thiểu sự tin cậy và bảo mật (kinh tế tiền điện tử) dựa trên khuyến khích. Trong phần giới thiệu bài viết này, chúng tôi trình bày tổng quan về Phi tập trung Oracle Networks trong Phần 1.1 và sau đó là bảy lĩnh vực đổi mới chính của chúng tôi trong Phần 1.2. Chúng tôi mô tả cách tổ chức phần còn lại của bài viết này trong Phần 1.3. 1.1 Mạng Oracle phi tập trung Mạng Oracle phi tập trung được thiết kế để nâng cao và mở rộng khả năng trong số smart contract trên mục tiêu blockchain hoặc chuỗi chính thông qua các chức năng không có sẵn nguyên bản. Họ làm như vậy bằng cách cung cấp ba nguồn lực cơ bản được tìm thấy trong Hệ thống máy tính: mạng, lưu trữ và tính toán. DON nhằm mục đích cung cấp những tài nguyên này có đặc tính bảo mật, toàn vẹn và sẵn có mạnh mẽ,1 như cũng như trách nhiệm giải trình. DON được thành lập bởi ủy ban của các nút oracle hợp tác để thực hiện một mục tiêu cụ thể việc làm hoặc chọn thiết lập mối quan hệ lâu dài để cung cấp dịch vụ lâu dài tới khách hàng. DON được thiết kế theo cách blockchain bất khả tri. Họ hứa sẽ phục vụ như một công cụ mạnh mẽ và linh hoạt dành cho các nhà phát triển ứng dụng để tạo ra sự hỗ trợ ngoài chuỗi cho smart contract của họ trên bất kỳ chuỗi chính nào được hỗ trợ. Hai loại chức năng nhận ra khả năng của DON: thực thi và bộ điều hợp. Tệp thực thi là các chương trình chạy liên tục và theo cách phi tập trung trên DON. Mặc dù chúng không trực tiếp lưu trữ tài sản trên chuỗi chính nhưng chúng có những lợi ích quan trọng, bao gồm hiệu suất cao và khả năng thực hiện bảo mật. tính toán. Các tệp thực thi chạy tự động trên DON và thực hiện xác định hoạt động. Chúng hoạt động cùng với các bộ điều hợp liên kết DON với các tài nguyên bên ngoài và có thể được gọi bởi các tệp thực thi. Bộ điều hợp, như chúng tôi hình dung cho DON, là một tổng quát về bộ điều hợp bên ngoài trong Chainlink ngày hôm nay. Trong khi các bộ điều hợp hiện có thường chỉ lấy dữ liệu từ các nguồn dữ liệu, bộ điều hợp có thể hoạt động hai chiều; trong DONs, họ có thể tận dụng thêm khả năng tính toán chung của các nút DON để đạt được các tính năng bổ sung, chẳng hạn như mã hóa báo cáo để sử dụng bảo vệ quyền riêng tư bằng cách một tệp thực thi. Để cung cấp ý nghĩa về hoạt động cơ bản của DON, Hình 1 cho thấy một cách khái niệm cách một DON có thể được sử dụng để gửi báo cáo tới blockchain và do đó đạt được chức năng oracle truyền thống, hiện có. Tuy nhiên, DON có thể cung cấp nhiều tính năng bổ sung 1“Bộ ba CIA” về bảo mật thông tin [123, tr. 26, §2.3.5].Mạng hiện có của Chainlink. Ví dụ, trong cấu trúc chung của Hình 1, tệp thực thi có thể ghi lại dữ liệu giá tài sản được tìm nạp trên DON, sử dụng dữ liệu đó để tính toán, ví dụ: trung bình kéo dài cho các báo cáo của nó. Hình 1: Hình minh họa dưới dạng ví dụ về cách Mạng Oracle phi tập trung có thể nhận ra chức năng oracle cơ bản, tức là chuyển tiếp dữ liệu ngoài chuỗi sang hợp đồng. Một thực thi sử dụng bộ điều hợp để tìm nạp dữ liệu ngoài chuỗi mà nó tính toán, gửi đầu ra qua một bộ chuyển đổi khác tới mục tiêu blockchain. (Bộ điều hợp được khởi tạo bằng mã trong DON, được biểu thị bằng các hộp nhỏ màu xanh; mũi tên chỉ hướng của luồng dữ liệu cho việc này ví dụ cụ thể.) Ngoài ra, tệp thực thi có thể đọc và ghi vào cục bộ DON lưu trữ để giữ trạng thái và/hoặc liên lạc với các tệp thực thi khác. Kết nối mạng, tính toán và lưu trữ linh hoạt trong DON giây, tất cả đều được trình bày ở đây, cho phép một loạt tính năng mới ứng dụng. Lợi ích chính của DON là khả năng khởi động các dịch vụ blockchain mới. DONs là phương tiện giúp các mạng oracle hiện có có thể nhanh chóng triển khai các ứng dụng dịch vụ điều đó ngày nay đòi hỏi phải tạo ra các mạng lưới được xây dựng có mục đích. Chúng tôi đưa ra một số ví dụ về các ứng dụng như vậy trong Phần 4. Trong Phần 3, chúng tôi cung cấp thêm chi tiết về DONs, mô tả khả năng của họ trong về giao diện mà họ trình bày cho nhà phát triển và người dùng. 1.2 Bảy mục tiêu thiết kế chính Ở đây chúng tôi xem xét ngắn gọn bảy trọng tâm chính được liệt kê ở trên về sự phát triển của Chainlink, cụ thể là:Lai smart contracts: Trọng tâm trong tầm nhìn của chúng tôi đối với Chainlink là ý tưởng về sự an toàn kết hợp các thành phần trên chuỗi và ngoài chuỗi trong smart contract giây. Chúng tôi đề cập đến hợp đồng hiện thực hóa ý tưởng này dưới dạng hợp đồng kết hợp smart contract hoặc hợp đồng kết hợp.2 Blockchain đang và sẽ tiếp tục đóng hai vai trò quan trọng trong dịch vụ phi tập trung hệ sinh thái: Cả hai đều là nơi thể hiện quyền sở hữu tiền điện tử và những mỏ neo vững chắc cho các dịch vụ phi tập trung. Do đó, các hợp đồng thông minh phải được thể hiện hoặc thực thi trên chuỗi, nhưng khả năng trên chuỗi của chúng bị hạn chế nghiêm trọng. hoàn toàn Mã hợp đồng trên chuỗi chậm, đắt tiền và thiếu chính xác, không thể hưởng lợi từ thế giới thực dữ liệu và nhiều chức năng vốn không thể thực hiện được trên chuỗi, bao gồm nhiều hình thức tính toán bí mật khác nhau, tạo ra tính bảo mật (giả) ngẫu nhiên chống lại thao tác khai thác / validator, v.v. Do đó, để smart contract phát huy hết tiềm năng của mình, cần phải có smart contracts được cấu trúc gồm hai phần: phần trên chuỗi (mà chúng tôi thường ký hiệu là SC) và một phần ngoài chuỗi, một phần thực thi chạy trên DON (mà chúng tôi thường biểu thị bằng thực thi). Mục tiêu là đạt được sự kết hợp an toàn của chức năng trên chuỗi với sự đa dạng của các dịch vụ ngoài chuỗi mà DON hướng tới cung cấp. Cùng nhau, hai phần tạo nên một hợp đồng lai. Chúng tôi trình bày ý tưởng này một cách khái niệm trong Hình 2. Ngày nay, Chainlink các dịch vụ3 như nguồn cấp dữ liệu và VRF đang bật nhưng không thể thực hiện được smart contract ứng dụng, từ DeFi đến NFT được tạo công bằng cho đến bảo hiểm phi tập trung, là những bước đầu tiên hướng tới một khuôn khổ tổng quát hơn. Là dịch vụ Chainlink mở rộng và phát triển hiệu quả hơn theo tầm nhìn của chúng tôi trong sách trắng này sức mạnh của hệ thống smart contract trên tất cả blockchains. Sáu trọng tâm chính khác của chúng tôi trong sách trắng này có thể được coi là hoạt động trong dịch vụ đầu tiên, bao quát một trong các hợp đồng kết hợp. Những trọng tâm này liên quan đến việc loại bỏ những gì có thể nhìn thấy sự phức tạp từ các hợp đồng kết hợp, tạo ra các dịch vụ ngoài chuỗi bổ sung cho phép xây dựng các hợp đồng kết hợp có năng lực cao hơn bao giờ hết, và trong trường hợp giảm thiểu lòng tin, củng cố các đặc tính bảo mật đạt được bằng các hợp đồng kết hợp. Chúng tôi để lại ý tưởng hợp đồng kết hợp tiềm ẩn trong phần lớn bài viết, nhưng bất kỳ sự kết hợp nào của Logic MAINCHAIN có DON có thể được xem là hợp đồng kết hợp. Trừu tượng hóa sự phức tạp: DON được thiết kế để tận dụng cơ chế phi tập trung hệ thống dễ dàng cho các nhà phát triển và người dùng bằng cách loại bỏ bộ máy thường phức tạp đằng sau mảng dịch vụ mạnh mẽ và linh hoạt của DONs. Dịch vụ Chainlink hiện có đã có tính năng này rồi. Ví dụ: nguồn cấp dữ liệu trong Chainlink ngày nay trình bày các giao diện onchain không yêu cầu nhà phát triển phải quan tâm đến chi tiết cấp độ giao thức, chẳng hạn như phương tiện mà OCR thực thi báo cáo đồng thuận giữa một 2Ý tưởng về thành phần hợp đồng trên chuỗi/ngoài chuỗi đã xuất hiện trước đây ở nhiều quốc gia bị ràng buộc khác nhau. các biểu mẫu, ví dụ: hệ thống lớp 2, blockchains [80] dựa trên TEE, v.v. Mục tiêu của chúng tôi là hỗ trợ và khái quát hóa những cách tiếp cận này và đảm bảo rằng chúng có thể bao gồm quyền truy cập dữ liệu ngoài chuỗi và khóa khác oracle dịch vụ. Các dịch vụ 3Chainlink bao gồm nhiều dịch vụ và chức năng phi tập trung có sẵn thông qua mạng lưới. Chúng được cung cấp bởi nhiều nhà khai thác nút được tạo thành các mạng oracle khác nhau khắp hệ sinh thái.Hình 2: Hình khái niệm mô tả thành phần hợp đồng trên chuỗi/ngoài chuỗi. A lai smart contract 3⃝bao gồm hai thành phần bổ sung: một trên chuỗi thành phần SC 1⃝, cư trú trên blockchain và người thực thi thành phần ngoài chuỗi 2⃝đó thực thi trên DON. DON cũng đóng vai trò là cầu nối giữa hai thành phần như kết nối hợp đồng lai với các tài nguyên ngoài chuỗi như dịch vụ web, các dịch vụ khác blockchains, lưu trữ phi tập trung, v.v. tập hợp các nút phi tập trung. DON tiến thêm một bước nữa theo nghĩa là chúng mở rộng phạm vi dịch vụ mà Chainlink có thể cung cấp cho nhà phát triển một lớp trừu tượng với đi kèm các giao diện được sắp xếp hợp lý cho các dịch vụ cấp cao. Chúng tôi trình bày một số ví dụ ứng dụng trong Phần 4 làm nổi bật cách tiếp cận này. Ví dụ: chúng tôi hình dung các doanh nghiệp sử dụng DON như một dạng phần mềm trung gian an toàn để kết nối các hệ thống cũ của họ với blockchains. (Xem Phần 4.2.) Việc sử dụng DON này giúp loại bỏ sự phức tạp của động lực chung blockchain (phí, tổ chức lại, v.v.). Nó cũng trừu tượng hóa các tính năng của blockchain cụ thể, từ đó cho phép doanh nghiệp kết nối các hệ thống hiện có của họ với một loạt các hệ thống blockchain ngày càng mở rộng mà không cần nhu cầu về chuyên môn chuyên môn trong các hệ thống này hoặc nói chung hơn là phát triển hệ thống phi tập trung. Cuối cùng, tham vọng của chúng tôi là nâng cao mức độ trừu tượng mà Chainlink đạt được đến mức triển khai những gì chúng tôi gọi là một siêu dữ liệu phi tập trung. Một lớp như vậy sẽ loại bỏ sự khác biệt trên chuỗi/ngoài chuỗi đối với tất cả các tầng lớp nhà phát triển và người dùng DApps, cho phép tạo và sử dụng liền mạch các dịch vụ phi tập trung.Để đơn giản hóa quá trình phát triển, các nhà phát triển có thể chỉ định chức năng DApp trong siêu dữ liệu dưới dạng một ứng dụng ảo trong mô hình máy thống nhất. Họ có thể sau đó sử dụng trình biên dịch siêu dữ liệu phi tập trung để tự động khởi tạo DApp như một tập hợp các chức năng phi tập trung tương tác trải dài blockchains, DONs và dịch vụ bên ngoài. (Một trong những dịch vụ bên ngoài này có thể là hệ thống doanh nghiệp, làm cho siêu lớp trở nên hữu ích cho các ứng dụng liên quan đến hệ thống doanh nghiệp cũ.) quá trình biên dịch giống như cách các trình biên dịch và bộ công cụ phát triển phần mềm (SDK) hiện đại hỗ trợ các lập trình viên tổng quát trong việc sử dụng toàn bộ tiềm năng của phần cứng không đồng nhất kiến trúc bao gồm CPU có mục đích chung và phần cứng chuyên dụng như GPU, máy gia tốc học máy hoặc các khu vực đáng tin cậy. Hình 3 trình bày ý tưởng này ở mức độ khái niệm. smart contract lai là bước đầu tiên trên con đường hướng tới tầm nhìn này và tới một khái niệm mà chúng tôi gọi là hợp đồng meta. Hợp đồng meta là các ứng dụng được mã hóa trên cơ sở phi tập trung metalayer và hoàn toàn bao gồm logic trên chuỗi (smart contracts), cũng như tính toán và kết nối ngoài chuỗi giữa các blockchain khác nhau và chuỗi ngoài hiện có dịch vụ. Do nhu cầu hỗ trợ ngôn ngữ và trình biên dịch, các mô hình bảo mật mới và Tuy nhiên, sự hài hòa về mặt khái niệm và kỹ thuật của các công nghệ khác nhau của một siêu dữ liệu phi tập trung thực sự là một mục tiêu đầy tham vọng mà chúng tôi mong muốn trong một thời gian dài chân trời thời gian. Tuy nhiên, đây là một mô hình lý tưởng hữu ích cần ghi nhớ khi đọc bài viết này, không được trình bày chi tiết ở đây, nhưng là điều chúng tôi dự định tập trung vào trong công việc tương lai của mình. Chainlink. Chia tỷ lệ: Mục tiêu có tầm quan trọng vượt trội trong các thiết kế đang phát triển của chúng tôi là cho phép Chainlink mạng để đáp ứng nhu cầu mở rộng quy mô ngày càng tăng của hệ sinh thái blockchain. Với tình trạng tắc nghẽn mạng đang trở thành một vấn đề tái diễn ở các nền tảng không được phép hiện có blockchains [86], các thiết kế mới và hiệu quả hơn blockchain sắp được đưa vào sử dụng, ví dụ: [103, 120, 203], cũng như các công nghệ chia tỷ lệ lớp 2 bổ sung, ví dụ: [5, 12, 121, 141, 169, 186, 187]. Các dịch vụ của Oracle phải đạt được độ trễ và thông lượng đáp ứng nhu cầu về hiệu suất của các hệ thống này đồng thời giảm thiểu phí trên chuỗi (ví dụ: chi phí gas) cho người vận hành hợp đồng cũng như người dùng thông thường. Với DONs, Chainlink chức năng nhằm mục đích tiến xa hơn và mang lại hiệu suất đủ cao cho các hệ thống thuần túy dựa trên web. DON nhận được phần lớn hiệu suất đạt được từ việc sử dụng các giao thức đồng thuận nhanh, dựa trên ủy ban hoặc không được phép mà họ kết hợp với blockchains họ hỗ trợ. Chúng tôi mong đợi nhiều DON với cấu hình khác nhau sẽ chạy song song; các DApp và người dùng khác nhau có thể điều hướng sự đánh đổi trong các lựa chọn đồng thuận cơ bản theo yêu cầu ứng dụng của họ. DONs có thể được xem dưới dạng công nghệ lớp 2. Chúng tôi kỳ vọng rằng trong số các dịch vụ khác, DONs sẽ hỗ trợ Khung thực thi giao dịch (TEF), khung này tạo điều kiện tích hợp hiệu quả DON và do đó oracle với các hiệu suất cao khác hệ thống lớp 2—ví dụ: rollups, các hệ thống kết hợp các giao dịch ngoài chuỗi để đạt được cải tiến hiệu suất. Chúng tôi giới thiệu TEF ở Phần 6.

Conceptual figure showing ideal realization of a decentralized metalayer that abstracts blockchain and DON complexity

Hình 3: Hình vẽ khái niệm cho thấy sự hiện thực hóa lý tưởng của một siêu dữ liệu phi tập trung. cho dễ phát triển, nhà phát triển chỉ định DApp, được đánh dấu bằng màu hồng, là một ứng dụng ảo ứng dụng trong mô hình máy thống nhất. Trình biên dịch siêu lớp phi tập trung sẽ tự động tạo ra các chức năng tương tác tương ứng: smart contracts (ký hiệu là bởi SC), logic (được biểu thị bằng exec) trên DONs, bộ điều hợp kết nối với các dịch vụ bên ngoài mục tiêu, v.v., như được biểu thị bằng phần đánh dấu màu vàng. Hình 4 thể hiện một cách khái niệm cách DON cải thiện tỷ lệ blockchain (smart contract) bằng cách tập trung giao dịch và xử lý báo cáo ngoại tuyến oracle, thay vì trên chuỗi. Sự thay đổi trong vị trí tính toán chính này làm giảm độ trễ giao dịch và phí trong khi thúc đẩy thông lượng giao dịch. Tính bảo mật: Chuỗi khối cung cấp tính minh bạch chưa từng có cho smart contract và các ứng dụng mà chúng hiện thực hóa. Nhưng có một sự căng thẳng cơ bản giữa tính minh bạch và tính bảo mật. Ví dụ, ngày nay, giao dịch trao đổi phi tập trung của người dùngHình 4: Hình khái niệm cho thấy Mạng Oracle phi tập trung cải thiện chia tỷ lệ blockchain được kích hoạt smart contract giây. Hình A ⃝hiển thị oracle thông thường kiến trúc. Giao dịch được gửi trực tiếp tới blockchain, cũng như báo cáo oracle. Do đó blockchain được đánh dấu màu vàng là vị trí chính để xử lý giao dịch. Hình B⃝cho thấy việc sử dụng DON để hỗ trợ các hợp đồng trên blockchain. Một DON thực thi xử lý các giao dịch cùng với dữ liệu từ các hệ thống bên ngoài và chuyển tiếp kết quả—ví dụ: giao dịch theo nhóm hoặc thay đổi trạng thái hợp đồng do tác động của giao dịch—đối với blockchain. Do đó, DON, được đánh dấu bằng màu vàng, là thông tin chính địa điểm xử lý giao dịch. các hành động được ghi lại trên chuỗi, giúp dễ dàng theo dõi hành vi trao đổi, nhưng cũng làm cho các giao dịch tài chính của người dùng được hiển thị công khai. Tương tự, dữ liệu được chuyển tiếp tới thiết bị thông minh hợp đồng vẫn còn trong chuỗi. Điều này làm cho dữ liệu đó có thể kiểm tra được một cách thuận tiện, nhưng hoạt động như không khuyến khích các nhà cung cấp dữ liệu muốn cung cấp smart contract thông tin nhạy cảm hoặc dữ liệu độc quyền. Chúng tôi tin rằng mạng oracle sẽ đóng vai trò then chốt trong việc thúc đẩy thế hệ tiếp theo các hệ thống kết hợp tính minh bạch vốn có của blockchains với các biện pháp bảo vệ bí mật mới. Trong bài viết này, chúng tôi chỉ ra cách họ sẽ làm như vậy bằng cách sử dụng ba phương pháp chính: • Bộ điều hợp bảo mật: Hai công nghệ được triển khai theo kế hoạch trong mạng của Chainlink, DECO [234] và Town Crier [233], hãy bật các nút oracle để truy xuất dữ liệu từ các hệ thống ngoài chuỗi theo cách bảo vệ dữ liệu và quyền riêng tư của người dùng tính bảo mật. Chúng sẽ đóng vai trò quan trọng trong việc thiết kế bộ điều hợp cho DONs. (Xem Phần 3.6.2 để biết chi tiết về hai công nghệ này.) • Tính toán bí mật: DONs có thể đơn giản che giấu tính toán của chúng khỏi việc dựa vào blockchains. Bằng cách sử dụng môi trường tính toán an toàn của nhiều bên và/hoặc môi trường thực thi đáng tin cậy, cũng có thể có tính bảo mật mạnh mẽ hơn trong đó các nút DON tính toán dữ liệu mà bản thân họ không có khả năng hiển thị.

Example comparing standard mining with Fair Sequencing Services showing how FSS prevents transaction reordering

Conceptual diagram of confidentiality-preserving operations in a DON processing sensitive data through adapters

• Hỗ trợ các hệ thống lớp 2 bí mật: TEF được thiết kế để hỗ trợ nhiều hệ thống lớp 2 khác nhau, nhiều hệ thống trong số đó sử dụng bằng chứng không có kiến thức để cung cấp các hình thức bảo mật giao dịch khác nhau. Chúng tôi thảo luận về các phương pháp này trong Phần 3 (với các chi tiết bổ sung trong Phần 6, Phụ lục B.1 và Phụ lục B.2). Hình 5 trình bày quan điểm khái niệm về cách dữ liệu nhạy cảm có thể truyền từ các nguồn bên ngoài đến smart contract bằng các bộ điều hợp bảo toàn bí mật và tính toán bí mật trong DON. Hình 5: Sơ đồ khái niệm về các hoạt động bảo mật trong DON trên dữ liệu nhạy cảm (được đánh dấu màu vàng). Dữ liệu nguồn nhạy cảm (vòng tròn đen) trên web máy chủ được trích xuất tới DON bằng cách sử dụng bộ điều hợp bảo mật (dòng màu xanh lam, mũi tên đôi). DON nhận dữ liệu dẫn xuất (vòng tròn rỗng) từ các bộ điều hợp này— kết quả của việc áp dụng một chức năng hoặc, ví dụ: chia sẻ bí mật, đối với nguồn nhạy cảm dữ liệu. Tệp thực thi trên DON có thể áp dụng tính toán bí mật cho dữ liệu dẫn xuất để tạo một báo cáo (vòng tròn kép), báo cáo này sẽ gửi qua bộ chuyển đổi tới blockchain. Chúng tôi tin rằng các công cụ mạnh mẽ để xử lý dữ liệu bí mật sẽ mở ra toàn bộ phạm vi ứng dụng. Trong số này có tài chính phi tập trung (và tập trung) tư nhân, danh tính phi tập trung, cho vay theo chuỗi dựa trên tín dụng, v.v. các quy trình nhận biết khách hàng và công nhận thân thiện với người dùng, như chúng tôi thảo luận trong Phần 4. Tính công bằng trong giao dịch: Thiết kế blockchain ngày nay có hơi bẩn một chút bí mật mở: Chúng được tập trung nhất thời. Người khai thác và validator có thể yêu cầu chuyểnhành động theo cách họ chọn. Lệnh giao dịch cũng có thể bị người dùng thao túng như một chức năng của phí mạng mà họ phải trả (ví dụ: giá gas ở Ethereum) và đối với một số phạm vi bằng cách tận dụng các kết nối mạng nhanh. Sự thao túng như vậy có thể, đối với Ví dụ: sử dụng hình thức chạy trước, trong đó tác nhân chiến lược như thợ mỏ quan sát giao dịch của người dùng và chèn giao dịch khai thác của chính nó vào giao dịch trước đó vị trí trong cùng một khối—đánh cắp tiền của người dùng một cách hiệu quả bằng cách tận dụng kiến thức nâng cao về giao dịch của người dùng. Ví dụ: bot có thể đặt lệnh mua trước của người dùng. Sau đó nó có thể tận dụng sự tăng giá tài sản do giao dịch của người dùng. Chạy trước bởi một số bot gây hại cho người dùng thông thường—tương tự như tần số cao giao dịch trên Phố Wall—đã phổ biến và được ghi chép rõ ràng [90], cũng như có liên quan các cuộc tấn công như chạy ngược [159] và bắt chước giao dịch tự động [195]. Các đề xuất nhằm hệ thống hóa việc khai thác đơn hàng của thợ mỏ thậm chí còn xuất hiện gần đây [110]. Các công nghệ lớp 2 như rollup không giải quyết được vấn đề mà chỉ tái tập trung hóa đặt hàng, đặt nó vào tay thực thể tạo ra rollup. Một trong những mục tiêu của chúng tôi là giới thiệu vào Chainlink một dịch vụ có tên là Sắp xếp theo thứ tự hợp lý Dịch vụ (FSS) [137]. FSS giúp smart contract nhà thiết kế đảm bảo thứ tự công bằng cho sản phẩm của họ giao dịch và tránh các cuộc tấn công chạy trước, chạy sau và các cuộc tấn công có liên quan vào giao dịch của người dùng cũng như các loại giao dịch khác, chẳng hạn như truyền báo cáo oracle. FSS cho phép DON triển khai các ý tưởng như khái niệm nghiêm ngặt, tạm thời về trật tự công bằng được giới thiệu trong [144]. Là một lợi ích ngẫu nhiên, FSS cũng có thể hạ thấp mạng của người dùng. phí (ví dụ: chi phí gas). Tóm lại, trong FSS, các giao dịch đi qua DON, thay vì truyền trực tiếp đến mục tiêu smart contract. DON yêu cầu giao dịch rồi chuyển tiếp chúng vào hợp đồng. Hình 6: Ví dụ về lợi ích của FSS. Hình A ⃝cho thấy cách một thợ mỏ khai thác nó quyền tập trung để đặt lệnh giao dịch, có thể hoán đổi một cặp giao dịch: giao dịch 1⃝ đến trước 2⃝, nhưng thay vào đó, người khai thác sẽ sắp xếp nó sau 2⃝. Ngược lại, Hình B⃝cho thấy cách DON phân quyền quy trình đặt hàng giữa các nút DON. Nếu số đại biểu các nút trung thực nhận được 1⃝trước 2⃝, FSS khiến 1⃝xuất hiện trước 2⃝trên chuỗi— ngăn chặn việc sắp xếp lại thứ tự của thợ mỏ bằng cách đính kèm các số thứ tự có thể thực thi theo hợp đồng. Hình 6 so sánh việc khai thác tiêu chuẩn với FSS. Nó cho thấy cách khai thác tiêu chuẩn,quá trình đặt hàng giao dịch được tập trung vào người khai thác và do đó phải tuân theo thao tác, chẳng hạn như sắp xếp lại một cặp giao dịch liên quan đến thời điểm chúng đến lần. Ngược lại, trong FSS, quy trình được phân cấp giữa các nút DON. Giả sử một nhóm các nút trung thực, FSS giúp thực thi các chính sách như sắp xếp thứ tự thời gian của giao dịch, giảm cơ hội thao túng của thợ mỏ và các thực thể khác. Ngoài ra, do người dùng không cần phải cạnh tranh để được ưu đãi đặt hàng dựa trên giá gas, họ có thể trả giá xăng tương đối thấp (trong khi các giao dịch từ DON có thể được thực hiện theo đợt để tiết kiệm gas). Giảm thiểu sự tin cậy: Mục đích chung của chúng tôi khi thiết kế DON là tạo điều kiện thuận lợi cho lớp hỗ trợ đáng tin cậy cho smart contract và các hệ thống phụ thuộc oracle khác bằng phương pháp phân cấp, công cụ mật mã và đảm bảo kinh tế mật mã. Bản thân DON đã được phân cấp và người dùng có thể chọn từ bất kỳ DON nào có sẵn hỗ trợ chuỗi chính mà họ muốn vận hành hoặc sinh ra thêm DONs với ủy ban của các nút mà họ tin tưởng. Tuy nhiên, đối với một số ứng dụng, đặc biệt là smart contracts, Chainlink người dùng có thể ưu tiên mô hình tin cậy coi chuỗi chính được DON hỗ trợ là đáng tin cậy hơn hơn chính DON. Đối với những người dùng như vậy, chúng tôi đã có hoặc có kế hoạch kết hợp vào kiến trúc của mạng Chainlink một số cơ chế cho phép hợp đồng trên chuỗi chính để tăng cường đảm bảo an ninh do DONs cung cấp, trong khi tại đồng thời cũng thực thi các biện pháp bảo vệ chống lại khả năng nguồn dữ liệu bị hỏng chẳng hạn như máy chủ web mà DON lấy dữ liệu từ đó. Chúng tôi mô tả các cơ chế này trong Phần 7. Chúng thuộc năm tiêu đề chính: • Xác thực nguồn dữ liệu: Công cụ cho phép nhà cung cấp dữ liệu ký điện tử dữ liệu của họ và do đó tăng cường chuỗi hành trình sản phẩm giữa nguồn gốc và hợp đồng dựa vào. • DON báo cáo thiểu số: Cờ được phát hành bởi một tập hợp con thiểu số của DON nút quan sát thấy sự sai trái của đa số trong DON. • Đường ray bảo vệ: Logic trên chuỗi chính phát hiện các điều kiện bất thường và tạm dừng hoặc tạm dừng thực hiện hợp đồng (hoặc đưa ra các biện pháp khắc phục khác). • Quản trị giảm thiểu sự tin cậy: Sử dụng các bản cập nhật phát hành dần dần để hỗ trợ việc kiểm tra cộng đồng cũng như các biện pháp can thiệp khẩn cấp phi tập trung để nhanh chóng ứng phó với các lỗi hệ thống. • Xác thực thực thể phi tập trung: Sử dụng cơ sở hạ tầng khóa công khai (PKI) để xác định các thực thể trong mạng Chainlink. Hình 7 trình bày sơ đồ khái niệm về các mục tiêu giảm thiểu lòng tin của chúng tôi. Bảo mật dựa trên khuyến khích (kinh tế tiền điện tử): Phân quyền tạo báo cáo trên các nút oracle giúp đảm bảo tính bảo mật ngay cả khi một số nút bị hỏng.

Conceptual diagram depicting super-linear scaling in Chainlink staking where briber cost grows faster than combined node deposits

Conceptual depiction of Chainlink trust-minimization goal showing DON and data source trust loci

Hình 7: Mô tả khái niệm về mục tiêu giảm thiểu sự tin cậy của Chainlink, đó là giảm thiểu nhu cầu của người dùng về hành vi chính xác của DON và các nguồn dữ liệu như web máy chủ. Điểm nổi bật màu vàng trong hình biểu thị các locus giảm thiểu độ tin cậy: DON và bộ máy chủ web cá nhân hoặc thiểu số. Điểm nổi bật màu hồng biểu thị các thành phần hệ thống có độ tin cậy cao theo giả định: hợp đồng trên blockchain và phần lớn của các máy chủ web, tức là các máy chủ web tổng hợp. Tuy nhiên, điều quan trọng không kém là đảm bảo rằng các nút có động cơ tài chính để hoạt động đúng đắn. Đặt cược, tức là yêu cầu các nút cung cấp tiền gửi LINK và cắt giảm (tịch thu) số tiền gửi này trong trường hợp có hành vi sai trái, sẽ đóng vai trò quan trọng trong Chainlink. Đây là một thiết kế khuyến khích quan trọng đã được sử dụng ở một số blockchain, ví dụ: [81, 103, 120, 204]. Tuy nhiên, việc đặt cược vào Chainlink trông rất khác so với staking ở chế độ độc lập blockchains. Đặt cược vào blockchain nhằm mục đích ngăn chặn các cuộc tấn công vào sự đồng thuận. Nó có một mục tiêu khác nhau trong Chainlink: đảm bảo gửi kịp thời các báo cáo chính xác oracle. Hệ thống staking được thiết kế tốt cho mạng oracle sẽ thực hiện các cuộc tấn công như hối lộ không có lợi cho đối thủ, ngay cả khi mục tiêu là smart contract có chỉ số cao giá trị tiền tệ. Trong bài viết này, chúng tôi trình bày cách tiếp cận chung với staking trong Chainlink bằng ba khóa đổi mới:1. Một mô hình đối nghịch mạnh mẽ bao gồm các cuộc tấn công bị bỏ qua trong cách tiếp cận. Một ví dụ là cái mà chúng tôi gọi là hối lộ tiềm năng. Đây là một hình thức hối lộ xác định nút nào nhận hối lộ trên cơ sở có điều kiện, ví dụ: đưa ra các khoản hối lộ được đảm bảo trước cho các nút mà cơ chế staking chọn tại ngẫu nhiên cho các vai trò cụ thể (chẳng hạn như kích hoạt việc xét xử báo cáo). 2. Tác động siêu tuyến tính staking, nghĩa là một cách không chính thức rằng để thành công, đối thủ phải có ngân sách $B lớn hơn tổng số tiền gửi của tất cả oracle nút. Chính xác hơn, chúng tôi muốn nói rằng đó là một hàm của n, \(B(n) ≫\)dn trong một mạng gồm n oracle nút, mỗi nút có số tiền gửi cố định $d (chính thức hơn, \(B(n) is asymptotically larger in n than \)dn). Hình 8 đưa ra một cái nhìn khái niệm về tài sản này. 3. Khung khuyến khích tiềm ẩn (IIF), một mô hình khuyến khích mà chúng tôi đã nghĩ ra để bao gồm các ưu đãi có thể đo lường được theo kinh nghiệm ngoài khoản tiền gửi rõ ràng staking tiền, bao gồm cả cơ hội tính phí trong tương lai của các nút. IIF mở rộng khái niệm về cổ phần ngoài tiền gửi nút rõ ràng. Hình 8: Sơ đồ khái niệm mô tả tỷ lệ siêu tuyến tính trong Chainlink staking. các hối lộ $B(n) mà đối thủ yêu cầu tăng nhanh hơn về n so với số tiền gửi tổng hợp $dn trong số tất cả các nút oracle. Chúng tôi cho thấy tác động của IIF và siêu tuyến tính staking cùng nhau tạo ra những gì chúng tôi gọi một chu kỳ an toàn kinh tế hiệu quả cho các mạng oracle. Khi người dùng mới vào

hệ thống, tăng thu nhập tiềm năng trong tương lai từ việc chạy các nút Chainlink, chi phí cận biên của an ninh kinh tế giảm đối với người sử dụng hiện tại và tương lai. Trong một chế độ cầu co giãn, chi phí giảm dần này sẽ khuyến khích thêm người dùng sử dụng mạng lưới, liên tục duy trì việc áp dụng trong một chu kỳ đạo đức đang diễn ra. Lưu ý: Mặc dù báo cáo chính thức này phác thảo các yếu tố quan trọng trong tầm nhìn của chúng tôi đối với sự phát triển của Chainlink nhưng nó không chính thức và bao gồm một số thông số kỹ thuật chi tiết. Chúng tôi dự định phát hành các tài liệu kỹ thuật tập trung vào các tính năng và phương pháp tiếp cận bổ sung khi chúng phát triển. Hơn nữa, điều quan trọng cần nhấn mạnh là nhiều yếu tố của tầm nhìn được trình bày ở đây (cải tiến quy mô, công nghệ bảo mật, FSS, v.v.) có thể và sẽ được triển khai ở dạng sơ bộ ngay cả trước khi DON nâng cao trở thành tính năng cơ bản của Chainlink. 1.3 Tổ chức của bài viết này Chúng tôi trình bày mô hình và ký hiệu bảo mật của mình trong Phần 2 và phác thảo Mô hình phi tập trung. API mạng Oracle trong Phần 3. Trong Phần 4, chúng tôi trình bày một số ví dụ về các ứng dụng mà DON cung cấp nền tảng triển khai hấp dẫn. Người đọc có thể tìm hiểu hầu hết các khái niệm chính của bài viết bằng cách đọc đến thời điểm này. Phần còn lại của bài viết có thêm chi tiết. Chúng tôi mô tả Trình tự hợp lý Dịch vụ (FSS) trong Phần 5 và Khung Thực thi Giao dịch (TEF) trong Phần 6. Chúng tôi mô tả cách tiếp cận của mình để giảm thiểu độ tin cậy trong Phần 7. Chúng tôi xem xét một số các yêu cầu triển khai DON quan trọng, cụ thể là triển khai tăng dần các tính năng, tư cách thành viên sổ cái động và trách nhiệm giải trình trong Phần 8. Cuối cùng, trong Phần 9, chúng tôi cung cấp tổng quan về cách tiếp cận đang phát triển của chúng tôi đối với thiết kế khuyến khích. Chúng tôi kết luận ở Phần 10. Để giúp những độc giả còn ít hiểu biết về các khái niệm trong bài viết này, chúng tôi cung cấp bảng chú giải thuật ngữ trong Phụ lục A. Chúng tôi trình bày chi tiết hơn về giao diện DON và chức năng trong Phụ lục B và trình bày một số bộ điều hợp mẫu trong Phụ lục C. Trong Phụ lục D, chúng tôi mô tả nguyên hàm mật mã cho nguồn dữ liệu được giảm thiểu độ tin cậy xác thực được gọi là chữ ký chức năng và giới thiệu một biến thể mới gọi là chữ ký chức năng rời rạc. Chúng tôi thảo luận về một số cân nhắc liên quan đến ủy ban lựa chọn cho DON trong Phụ lục F.

Conceptual figure showing how DONs improve blockchain smart contract scaling by moving computation off-chain

Conceptual figure depicting on-chain and off-chain contract composition in a hybrid smart contract architecture

導入

Conceptual figure showing how a Decentralized Oracle Network can realize basic oracle functionality by relaying off-chain data to a contract

ブロックチェーン oracle は、現在、次の 1 つの目的を備えた分散型サービスとして見なされていることがよくあります。 オフチェーン リソースから blockchain にデータを転送します。短いステップではありますが、 データの転送から、データの計算、保存、双方向の送信まで。この観察は、oracles の機能についてのより広い概念を正当化します。それもそうだ smart contract の増加し、ますます多面化するサービス要件に対応します oracle ネットワークに依存するテクノロジー。つまり、oracle は次のことを行うことができ、またそうする必要があります。 オンチェーン システムとオフチェーン システムの間の汎用、双方向、コンピューティング対応インターフェイスであること。 blockchain エコシステムにおけるオラクルの役割は、 smart contract のパフォーマンス、機能、相互運用性を向上させ、 さまざまな業界に新しい信頼モデルと透明性をもたらします。この変革は、ハイブリッド smart contract の使用を拡大することによって実現されます。 blockchains の特別なプロパティと、オフチェーン システムの独自の機能を備えた次のような oracle ネットワークを利用することで、オンチェーン システムよりもはるかに大きな到達範囲とパワーを実現します。 孤立して。 このホワイトペーパーでは、Chainlink 2.0 と呼ばれるもののビジョンを明確に示します。これは、元の Chainlink ホワイトペーパー [98] の初期概念を超えた Chainlink の進化です。 oracle ネットワークの役割はますます拡大すると予想されます。 これらは、ハイブリッド向けに高速で信頼性が高く、機密性を保持するユニバーサルな接続と計算機能を提供することにより、既存および新しい blockchain を補完および強化します。 smart contract秒。私たちは、oracle ネットワークが進化してユーティリティになると信じています 高整合性 blockchain グレードのデータを blockchain 以降のシステムにエクスポートするため 生態系。 現在、さまざまなエンティティのセットによって実行される Chainlink ノードが oracle ネットワークに集まり、いわゆるレポートでデータを smart contract に中継します。そのようなものを見ることができます oracle ノードは、古典的なコンセンサス blockchain [72] と同様の委員会として、 ただし、独立した機能を提供するのではなく、既存の blockchain をサポートすることを目的としています。検証可能なランダム関数 (VRF) とオフチェーン レポート機能を搭載 (OCR)、Chainlink は、smart contract が必要とする計算リソースを提供するための汎用フレームワークとインフラストラクチャに向けてすでに進化しています。 高度な機能。 Chainlink 2.0 の計画の基礎となるのは、分散型 Oracle と呼ばれるものです。 ネットワーク、略して DONs。 「oracle ネットワーク」という用語を オリジナルの Chainlink ホワイトペーパー [98]、oracle はさらに豊富な機能を開発し、 応用範囲の広さ。この論文では、以下に従ってこの用語の新たな定義を提供します。 Chainlink エコシステムの将来のビジョンに向けて。このビューでは、DON はネットワークです Chainlink ノードの委員会によって維持されています。コンセンサスプロトコルに基づいており、 によって展開用に選択された無制限の範囲の oracle 関数のいずれかをサポートします。 委員会。したがって、DON は blockchain 抽象化レイヤーとして機能し、インターフェイスを提供します smart contract と他のシステムの両方のリソースをオフチェーンにします。また、 非常に効率的でありながら分散化されたオフチェーン コンピューティング リソースへのアクセス。一般に、 DON はメインチェーンでの操作をサポートします。その目標は、安全かつ柔軟なセキュリティを実現することです。オンチェーンとオフチェーンの計算を組み合わせたハイブリッド smart contracts 外部リソースへの接続。 DON で委員会を利用したとしても、Chainlink 自体は 本質的にパーミッションレスのままです。 DON はパーミッションレスの基盤として機能します ノードが連携してカスタム oracle ネットワークを実装できるフレームワーク ノードを含めるための独自の体制。これは許可されている場合と許可されていない場合があります。 DONs を基盤として、Chainlink 2.0 では 7 つの機能の進歩に重点を置く予定です。 主要領域: ハイブリッド smart contract、複雑さの抽象化、スケーリング、機密性、トランザクションの順序の公平性、信頼の最小化、インセンティブ ベースの (暗号経済) セキュリティ。この論文の紹介では、分散型の概要を紹介します。 セクション 1.1 では Oracle ネットワークについて説明し、セクション 1.2 ではイノベーションの 7 つの主要分野について説明します。この文書の残りの構成についてはセクション 1.3 で説明します。 1.1 分散型 Oracle ネットワーク 分散型 Oracle ネットワークは、機能を強化および拡張するように設計されています。 ターゲット blockchain または関数を介したメイン チェーン上の smart contract の数 ネイティブでは利用できません。彼らは、次の 3 つの基本リソースを提供することでこれを実現します。 コンピューティング システム: ネットワーキング、ストレージ、およびコンピューティング。 DON の目的は、 これらのリソースは、強力な機密性、完全性、および可用性の特性1を備えています。 説明責任も。 DON は、特定の条件を満たすために協力する oracle ノードの委員会によって形成されます。 仕事を続けるか、永続的なサービスを提供するために長期的な関係を築くことを選択します クライアントへ。 DON は、blockchain に依存しない方法で設計されています。彼らは次のように奉仕することを約束します アプリケーション開発者がオフチェーン サポートを作成するための強力で柔軟なツール サポートされているメイン チェーン上の smart contract。 DON の機能は、実行可能ファイルと実行可能ファイルの 2 種類の機能によって実現されます。 アダプター。実行可能ファイルは、DON 上で継続的かつ分散的に実行されるプログラムです。メインチェーン資産を直接保存するわけではありませんが、高いパフォーマンスや機密情報を実行する機能など、重要な利点があります。 計算。実行可能ファイルは DON 上で自律的に実行され、決定論的に実行されます。 操作。これらは、DON を外部リソースにリンクするアダプターと連携して動作します。 実行可能ファイルによって呼び出される可能性があります。私たちが DON 向けに想定しているアダプターは、 本日、Chainlink で外部アダプターが一般化されました。既存のアダプターを使用しながら、 通常、アダプターはデータ ソースからデータをフェッチするだけですが、アダプターは双方向で動作する場合があります。で DON では、DON ノードによる共同計算をさらに利用して、次のことを達成する場合があります。 プライバシーを保護して利用するためのレポートの暗号化などの追加機能 実行可能ファイル。 DON の基本的な動作を理解するために、図 1 に、DON がどのように動作するかを概念的に示します。 DON は、レポートを blockchain に送信するために使用され、従来の既存の oracle 機能を実現できます。 DONs は多くの追加機能を提供しますが、それ以外にも 1 情報セキュリティの「CIA トライアド」 [123、p. 26、§2.3.5]。Chainlink の既存のネットワーク。たとえば、図 1 の一般的な構造内では、 実行可能ファイルは、取得した資産価格データを DON に記録し、そのようなデータを使用して たとえば、レポートの末尾平均を計算します。 図 1: 分散型 Oracle ネットワークが基本的な oracle 機能、つまりオフチェーン データをコントラクトに中継する方法を例として示す概念図。アン 実行可能ファイルはアダプターを使用してオフチェーン データを取得し、そのデータに基づいて計算し、出力を送信します 別のアダプターを介してターゲット blockchain に接続します。 (アダプターは、 DON、小さな青いボックスで表されます。矢印は、このデータ フローの方向を示します。 特定の例。) 実行可能ファイルは、ローカル DON への読み取りと書き込みも可能です。 状態を保持したり、他の実行可能ファイルと通信したりするためのストレージ。ここに示されている DONs の柔軟なネットワーキング、コンピューティング、およびストレージは、さまざまな新しい機能を可能にします。 アプリケーション。 DON の主な利点は、新しい blockchain サービスをブートストラップできることです。 DONs 既存の oracle ネットワークがサービス アプリケーションを迅速に立ち上げることができる手段です それには今日では専用のネットワークの構築が必要になります。いくつか挙げます このようなアプリケーションの例はセクション 4 で説明します。 セクション 3 では、DON について詳しく説明し、その機能について説明します。 開発者とユーザーに提示するインターフェイスの用語。 1.2 7 つの主要な設計目標 ここでは、上で列挙した 7 つの重要な焦点を簡単にレビューします。 Chainlink、つまり:ハイブリッド smart contracts: Chainlink に対する当社のビジョンの中心となるのは、安全性を確保するという考えです。 smart contracts でオンチェーン コンポーネントとオフチェーン コンポーネントを組み合わせます。契約書を参照します このアイデアは、ハイブリッド smart contract またはハイブリッド コントラクトとして実現されます。2 ブロックチェーンは、分散型サービスにおいて 2 つの重要な役割を現在も果たし続けます。 エコシステム: どちらも暗号通貨の所有権が表現される場所です 分散型サービスのための堅牢なアンカー。したがって、スマート コントラクトはチェーン上で表現または実行される必要がありますが、そのオンチェーン機能は大幅に制限されています。純粋に オンチェーンコントラクトコードは遅く、高価で、閉鎖的であり、現実世界の恩恵を受けることができない データと、さまざまな形式の機密計算、安全な (擬似) 乱数の生成など、チェーン上では本質的に実現不可能なさまざまな機能 マイナー / validator 操作などに対して。 したがって、smart contracts がその可能性を最大限に発揮するには、smart contracts が必要です。 オンチェーン部分 (通常、SC で表します) の 2 つの部分で設計されます。 オフチェーン部分、DON 上で実行される実行可能ファイル (通常、これを次のように表します) 実行)。目標は、オンチェーン機能の安全な構成を達成することです。 DON が提供しようとしている多数のオフチェーン サービス。 2 つの部分を合わせて、 ハイブリッド契約を締結します。このアイデアを概念的に図 2 に示します。 Chainlink データ フィードや VRF などのサービス3 により、他の方法では実現できないことが可能になります smart contract アプリケーションは、DeFi から適切に生成された NFT、分散型保険に至るまで、より一般的なフレームワークに向けた最初のステップとして提供されます。 Chainlink サービスとして このホワイトペーパーのビジョンに従って拡張し、よりパフォーマンスを向上させます。 すべての blockchain にわたって smart contract システムのパワーが発揮されます。 このホワイトペーパーの他の 6 つの主要な焦点は、サービス内で機能するとみなされる場合があります。 ハイブリッド契約の最初の最も重要な契約の 1 つです。これらの焦点には、目に見えるものを取り除くことが含まれます ハイブリッド契約による複雑さにより、追加のオフチェーン サービスが作成され、 これまで以上に有能なハイブリッド契約の構築、および信頼の最小化の場合には、ハイブリッド契約によって達成されるセキュリティ特性が強化されます。アイデアは残しておきます ハイブリッド契約は文書の大部分で暗黙的に示されていますが、これらの組み合わせは、 DON を持つ MAINCHAIN ロジックは、ハイブリッド コントラクトとして見なすことができます。 複雑さを抽象化する: DON は、分散型を利用するように設計されています。 複雑になりがちな機構を抽象化することで、開発者とユーザーにとって使いやすいシステムを実現 DONs の強力で柔軟な一連のサービスの背後にあります。 既存の Chainlink サービス すでにこの機能を持っています。 たとえば、Chainlink のデータ フィードは、開発者がプロトコル レベルの詳細 (OCR がユーザー間でコンセンサス レポートを強制する手段など) を気にする必要のないオンチェーン インターフェイスを提供しています。 2オンチェーン/オフチェーンの契約構成という考え方は、これまでさまざまな制約条件の中で生じてきました。 レイヤー 2 システム、TEE ベースの blockchains [80] などのフォームをサポートし、一般化することが私たちの目標です。 これらのアプローチを採用し、オフチェーン データ アクセスやその他の重要な鍵を確実に包含できるようにします oracle サービス。 3Chainlink サービスは、さまざまな分散型サービスと機能で構成されます。 ネットワーク。これらは、さまざまな oracle ネットワークを構成する多数のノード オペレーターによって提供されます。 生態系全体で。図 2: オンチェーン/オフチェーンの契約構成を示す概念図。あ ハイブリッド smart contract 3⃝ 2 つの補完的なコンポーネントで構成されます: オンチェーン blockchain に常駐するコンポーネント SC 1⃝、およびオフチェーン コンポーネント exec 2⃝ DON で実行されます。 DON は 2 つのコンポーネント間のブリッジとしても機能します ハイブリッド コントラクトを Web サービスなどのオフチェーン リソースと接続するなど、 blockchains、分散ストレージなど。 分散されたノードのセット。 DON は、 Chainlink が開発者に提供できるサービス範囲 高レベルのサービスのための合理化されたインターフェイスが付属しています。 セクション 4 では、このアプローチを強調するいくつかの応用例を示します。 たとえば、企業が DONs を安全なミドルウェアの形式として使用して、 レガシー システムを blockchain に接続します。 (セクション 4.2 を参照してください。) この DON の使用により、一般的な blockchain ダイナミクス (手数料、再組織など) の複雑さが抽象化されます。それも 特定の blockchain の機能を抽象化することで、企業は既存のシステムを、ますます拡大する blockchain システムに接続することができます。 これらのシステム、またはより一般的には分散システム開発における専門知識が必要です。 最終的に、私たちの目標は、Chainlink によって達成される抽象度を高めることです。 私たちが分散型メタレイヤーと呼ぶものを実装するところまで。そんな層 すべてのクラスの開発者にとってオンチェーンとオフチェーンの区別が抽象化されます。 と DApps のユーザーにより、分散型サービスのシームレスな作成と使用が可能になります。開発プロセスを簡素化するために、開発者はメタレイヤーで DApp 機能を統合マシン モデルの仮想アプリケーションとして指定できます。彼らはできるだろう 次に、分散メタレイヤー コンパイラーを使用して、DApp を次のように自動的にインスタンス化します。 blockchains、DONs、および 外部サービス。 (これらの外部サービスの 1 つはエンタープライズ システムである可能性があり、メタレイヤーはレガシー エンタープライズ システムに関係するアプリケーションに役立ちます。) コンパイルは、最新のコンパイラーやソフトウェア開発キット (SDK) の仕組みに似ています。 異種ハードウェアの可能性を最大限に活用できるジェネラリスト プログラマーをサポートします。 汎用CPUとGPUなどの専用ハードウェアで構成されるアーキテクチャ、 機械学習アクセラレータ、または信頼されたエンクレーブ。図 3 は、このアイデアを概念的なレベルで示しています。 ハイブリッド smart contract は、このビジョンと、メタ コントラクトと呼ばれる概念への第一歩です。メタコントラクトは、分散型でコーディングされたアプリケーションです。 メタレイヤーに含まれ、オンチェーン ロジック (smart contracts) だけでなく、オフチェーンの計算と、さまざまな blockchain と既存のオフチェーン間の接続も暗黙的に包含されます。 サービス。言語とコンパイラのサポート、新しいセキュリティ モデル、および ただし、異種テクノロジーの概念的および技術的調和は実現可能 真の分散型メタレイヤーの実現は、私たちが長期にわたって目指している野心的な目標です 時間の地平線。それでも、これは、読んでいるときに覚えておくと役立つ理想的なモデルです。 この論文については、ここでは詳しく説明しませんが、今後の作業で焦点を当てていく予定です。 Chainlink。 スケーリング: 進化するデザインにおいて非常に重要な目標は、 Chainlink ネットワークは、blockchain エコシステムの増大するスケーリング ニーズに対応します。 既存のパーミッションレスではネットワークの輻輳が繰り返し問題になる中、 blockchains [86]、新しくてより高性能な blockchain デザインが使用され始めています。 例: [103, 120, 203]、および補完的なレイヤー 2 スケーリング技術 (例: [5, 12、121、141、169、186、187]。 Oracle サービスはレイテンシとスループットを達成する必要があります オンチェーン手数料を最小限に抑えながら、これらのシステムのパフォーマンス要求を満たします 契約事業者も一般ユーザーも同様に（例：ガス料金）。 DON、Chainlink を使用 この機能はさらに進化し、純粋な Web ベースのシステムに十分なパフォーマンスを提供することを目指しています。 DON は、パフォーマンス向上の多くを、blockchain と組み合わせた、高速な委員会ベースまたはパーミッションレスのコンセンサス プロトコルの使用から得ています。 彼らはサポートします。さまざまな構成の多くの DON が並行して実行されることが予想されます。さまざまな DApp とユーザーが、基礎となるコンセンサスの選択におけるトレードオフをナビゲートできる アプリケーション要件に応じて。 DON は、実質的にレイヤー 2 テクノロジーとみなされる場合があります。 私たちは次のことを期待しています 他のサービス、DONs はトランザクション実行フレームワーク (TEF) をサポートします。 DON、つまり oracle と他の高性能製品との効率的な統合が容易になります。 レイヤ 2 システム - 例: rollups、トランザクションをオフチェーンにバンドルして達成するシステム パフォーマンスの向上。 TEF についてはセクション 6 で紹介します。

Conceptual figure showing ideal realization of a decentralized metalayer that abstracts blockchain and DON complexity

図 3: 分散メタレイヤーの理想的な実現を示す概念図。のために 開発が容易なため、開発者は仮想アプリケーションとしてピンク色で強調表示された DApp を指定します。 統合されたマシンモデルでのアプリケーション。分散メタレイヤー コンパイラーは、対応する相互運用機能を自動的に生成します: smart contracts (示されています) SC による)、DONs 上のロジック (exec で示される)、ターゲットの外部サービスに接続するアダプターなど (黄色のハイライトで示されています)。 図 4 は、DON が blockchain (smart contract) スケーリングをどのように改善するかを概念的に示しています トランザクションとoracleレポートの処理をオフチェーンに集中させることで、 チェーン。計算の主な領域におけるこのシフトにより、トランザクションの待ち時間が短縮され、 トランザクションのスループットを向上させながら手数料を削減します。 機密保持: ブロックチェーンは、smart contract とそれが実現するアプリケーションに前例のない透明性を提供します。しかし、透明性と機密性の間には基本的な緊張関係があります。たとえば今日、ユーザーの分散型取引所の取引は、図 4: 分散型 Oracle ネットワークがどのようにネットワークを改善するかを示す概念図 blockchain 対応の smart contract のスケーリング。図A ⃝従来のoracleを示します 建築。トランザクションは、oracle レポートと同様に、blockchain に直接送信されます。 したがって、黄色で強調表示されている blockchain がトランザクション処理の主な場所です。図 B⃝は、blockchain のコントラクトをサポートするための DON の使用を示しています。 DON 実行可能ファイルは、外部システムからのデータとともにトランザクションを処理し、転送します。 結果 (バンドルされたトランザクションやトランザクションの影響による契約状態の変更など) を blockchain に送信します。したがって、黄色で強調表示されている DON がメインです トランザクション処理の場所。 アクションはチェーン上に記録されるため、交換の動作を簡単に監視できますが、 ユーザーの金融取引を一般に公開します。同様に、スマートに中継されるデータ 契約は連鎖的に残ります。これにより、そのようなデータは簡単に監査可能になりますが、次のように機能します。 smart contract に機密情報や機密データを提供したいと考えるデータプロバイダーにとっては阻害要因となります。 独自のデータ。 私たちは、oracle ネットワークが次世代の触媒となる重要な役割を果たすと信じています。 blockchains 本来の透明性と新しい機密保護を組み合わせたシステムです。このペーパーでは、次の 3 つの主なアプローチを使用して、どのようにそれを行うかを示します。 • 機密保持アダプター: 計画的に展開される 2 つのテクノロジー Chainlink のネットワーク、DECO [234] および Town Crier [233] では、oracle ノードが ユーザーのプライバシーとデータを保護する方法でオフチェーン システムからデータを取得する 機密保持。これらは、DON のアダプターの設計において重要な役割を果たします。 (これら 2 つのテクノロジーの詳細については、セクション 3.6.2 を参照してください。) • 機密の計算: DONs は、blockchains に依存しないように単純に計算を隠すことができます。安全なマルチパーティ コンピューティングや信頼できる実行環境を使用すると、DON ノードでの機密性を強化することも可能です。 それ自体が可視性を持たないデータを計算します。

Example comparing standard mining with Fair Sequencing Services showing how FSS prevents transaction reordering

Conceptual diagram of confidentiality-preserving operations in a DON processing sensitive data through adapters

• 機密のレイヤー 2 システムのサポート: TEF は、さまざまなレイヤー 2 システムをサポートするように設計されており、その多くはゼロ知識証明を使用して、 さまざまな形の取引機密保持。 これらのアプローチについてはセクション 3 で説明します (詳細はセクション 6、付録 B.1、および付録 B.2 で説明します)。 図 5 は、機密データが機密性保持アダプターおよび DON での機密計算。 図 5: DON における機密保持オペレーションの概念図 機密データ (黄色で強調表示)。 Web 内の機密ソース データ (黒丸) サーバーは、機密保持アダプター (青色の二重矢印線) を使用して DON に抽出されます。 DON は、これらのアダプターから派生データ (白丸) を受け取ります。 機密情報源に関数または秘密共有などを適用した結果 データ。 DON 上の実行可能ファイルは、派生データに機密計算を適用する可能性があります レポート (二重丸) を作成し、アダプター経由で blockchain に送信します。 私たちは、機密データを扱うための強力なツールによって、あらゆる問題が解決されると信じています。 応用範囲。 その中には、民間の分散型（および集中型）金融、分散型アイデンティティ、クレジットベースのオンチェーン融資、およびより効率的かつ効率的な融資が含まれます。 セクション 4 で説明する、ユーザーフレンドリーな顧客認識プロトコルと認定プロトコル。 トランザクションの注文の公平性: 今日のblockchainのデザインには少し汚れがあります 公然の秘密: これらは一時的に集中化されます。マイナーと validator は取引を注文できます。彼らが選択した行動。トランザクション順序は、ユーザーが次のように操作することもできます。 彼らが支払うネットワーク料金の関数 (例: Ethereum のガソリン価格) 高速ネットワーク接続を利用して、範囲を拡大できます。このような操作により、 たとえば、鉱山労働者などの戦略的主体がフロントランニングの形をとります。 ユーザーのトランザクションを監視し、独自の搾取的なトランザクションを以前のトランザクションに挿入します。 ユーザーの取引に関する事前の知識を利用して、ユーザーから効果的にお金を盗みます。たとえば、ボットが買い注文を出す場合があります。 ユーザーの前に。そして、それによって引き起こされる資産価格の上昇を利用することができます。 ユーザーの取引。 一般ユーザーに害を及ぼす一部のボットによるフロントランニング (高頻度に類似) ウォール街での取引 - 関連するものとして、すでに普及しており、十分に文書化されています [90] バックランニング [159] や [195] を模倣する自動トランザクションなどの攻撃。マイナーによる注文の搾取を体系化するという提案も、最近 [110] で浮上しています。 rollups などのレイヤー 2 テクノロジーは問題を解決するものではなく、単に再集中化するだけです 注文して、rollup を作成するエンティティの手に渡します。 私たちの目標の 1 つは、Chainlink に Fair Sequencing と呼ばれるサービスを導入することです。 サービス (FSS) [137]。 FSS は、smart contract デザイナーが公正な発注を保証するのに役立ちます ユーザー トランザクションや他のタイプのトランザクション (oracle レポート送信など) に対するフロントランニング攻撃、バックランニング攻撃、および関連する攻撃を回避します。 FSS DON は、[144] で導入された順序の公平性の厳密で時間的な概念などのアイデアを実装できるようになります。付随的な利点として、FSS はユーザーのネットワークを低下させることもできます 料金（ガソリン代など）。 簡単に説明すると、FSS では、トランザクションはターゲット smart contract に直接伝播するのではなく、DON を通過します。 DON はトランザクションを注文して転送します。 彼らを契約に結び付けます。 図 6: FSS がどのように役立つかの例。図A ⃝マイナーがその能力をどのように活用するかを示します。 トランザクションの注文権限を集中管理し、トランザクションのペアを交換する場合があります: トランザクション 1⃝ は 2⃝ より前に到着しますが、マイナーは代わりに 2⃝ より後に配列します。対照的に、図 B⃝ は次のようになります。 DON が DON ノード間で注文プロセスをどのように分散化するか。定足数が満たされている場合 正直なノードは 2⃝ の前に 1⃝ を受け取ります。FSS により、チェーン上で 1⃝ が 2⃝ の前に表示されます。 契約で強制可能なシーケンス番号を付加することで、マイナーの並べ替えを防止します。 図 6 は、標準マイニングと FSS を比較しています。標準的なマイニングでどのように行われるかを示しています。トランザクションの順序付けのプロセスはマイナーによって集中化されるため、 到着に応じてペアのトランザクションを並べ替えるなどの操作 回。対照的に、FSS では、プロセスは DON ノード間で分散されます。仮定すると 正直なノードのクォーラムである FSS は、ノードの一時的な順序付けなどのポリシーを強制するのに役立ちます。 トランザクションを保護し、マイナーやその他の組織による操作の機会を減らします。 また、ユーザーはガソリン価格に基づいて優先注文を競う必要がないため、 比較的低いガソリン価格を支払うことができます (DON からのトランザクションはバッチ処理できます) ガスの節約のため）。 信頼の最小化: DONs の設計における一般的な目的は、高度な設計を容易にすることです。 smart contract およびその他の oracle に依存するシステムの信頼できるサポート層 分散化、暗号化ツール、暗号経済的保証によって。 DON 自体は分散化されており、ユーザーは利用可能な DON から選択できます。 追加の DON を操作または生成するメイン チェーンをサポートします。 彼らが信頼するノードの委員会と。 ただし、一部のアプリケーション、特に smart contracts、Chainlink のユーザーは、 DON によってサポートされるメイン チェーンをより信頼できるものとして扱う信頼モデルを好む DON 自体よりも。そのようなユーザーのために、私たちはすでに、または導入する予定の Chainlink ネットワークのアーキテクチャ コントラクトを可能にする多数のメカニズム DONs によって提供されるセキュリティ保証を強化するためにメイン チェーン上で、 同時に、データ ソースが破損する可能性に対する保護も強化します。 DON がデータを取得する Web サーバーなど。 これらのメカニズムについてはセクション 7 で説明します。それらは 5 つの主要な見出しに分類されます。 • データソース認証: データプロバイダーがデジタル署名できるようにするツール データを収集し、それによって、発信元とデータの間の保管連鎖を強化します。 信頼できる契約。 • DON マイノリティ レポート: DON ノードのマイノリティ サブセットによって発行されるフラグ。 DON における大多数の不正行為を観察します。 • ガードレール: 異常な状態を検出して一時停止するメインチェーン上のロジック または契約の実行を停止します（または他の是正措置を講じます）。 • 信頼を最小限に抑えたガバナンス: コミュニティの検査を容易にするための段階的リリースのアップデートの使用と、迅速な対応のための分散型の緊急介入。 システム障害への対応。 • 分散型エンティティ認証: 公開キー基盤 (PKI) を使用して、 Chainlink ネットワーク内のエンティティを識別します。 図 7 は、信頼最小化の目標の概念図を示しています。 インセンティブベースの (暗号経済的) セキュリティ: oracle ノード間でレポート生成を分散化することで、一部のノードが破損した場合でもセキュリティを確保できます。

Conceptual diagram depicting super-linear scaling in Chainlink staking where briber cost grows faster than combined node deposits

Conceptual depiction of Chainlink trust-minimization goal showing DON and data source trust loci

図 7: Chainlink の信頼最小化目標の概念図。 DON および Web などのデータ ソースの正しい動作に対するユーザーのニーズを最小限に抑える サーバー。図内の黄色のハイライトは、信頼最小化遺伝子座、DON および 個別または少数の Web サーバーのセット。ピンクのハイライトはシステムコンポーネントを示します 仮定により非常に信頼できるもの: blockchain と過半数に関する契約 Web サーバーの数、つまり Web サーバーの集合体。 ただし、同様に重要なのは、ノードが正しく動作するための経済的インセンティブを確保することです。ステーキング、つまりノードにリンクとスラッシュのデポジットを提供するよう要求する 不正行為があった場合にこれらの預金を没収することは、Chainlink において重要な役割を果たします。これは、すでに多くの blockchain で使用されている重要なインセンティブ デザインです。 例: [81、103、120、204]。 ただし、Chainlink でのステーキングは、スタンドアロンの staking とは大きく異なります。 blockchain秒。 blockchains へのステーキングは、コンセンサスへの攻撃を防ぐことを目的としています。それは Chainlink の別の目標: 正しい oracle レポートをタイムリーに配信すること。 oracle ネットワーク用に適切に設計された staking システムでは、贈収賄などの攻撃が行われるはずです たとえターゲットが高強度のsmart contractであっても、敵にとって利益はありません。 金銭的価値。 このペーパーでは、3 つのキーを使用した Chainlink の staking への一般的なアプローチを示します。 イノベーション:1. 既存の攻撃では見落とされていた攻撃を包含する強力な敵対的モデル 近づいてきます。一例として、いわゆる「見込贈収賄」が挙げられます。これは次の形式です どのノードが賄賂を受け取るかを条件に基づいて決定する賄賂。 staking メカニズムが選択したノードに事前に保証された賄賂を提供します。 特定の役割に対してランダム（レポートの裁定をトリガーするなど）。 2. 超線形 staking インパクト。非公式には、成功するには、敵対者はすべての oracle のデポジットの合計より $B 大きい予算を持っている必要があることを意味します。 ノード。 より正確には、n の関数として、\(B(n) ≫\)dn が n oracle ノードのネットワークで、それぞれに固定デポジット額 $d が設定されています (より正式には、 \(B(n) is asymptotically larger in n than \)dn)。図 8 に概念図を示します。 この物件。 3. 暗黙的インセンティブ フレームワーク (IIF)、これは当社が考案したインセンティブ モデルです。 明示的な入金を超えた経験的に測定可能なインセンティブを含む staking ノードの将来の手数料機会を含む資金。 IIF は次の概念を拡張します。 明示的なノードデポジットを超えるステーク。 図 8: Chainlink staking におけるスーパーリニア スケーリングを示す概念図。の 敵対者が要求する賄賂 $B(n) は、合計の預金額よりも n 倍の速さで増加します すべての oracle ノードの $dn。 IIF と超線形 staking の影響がどのように連携して引き起こされるのかを示します。 oracle ネットワークの経済安全の好循環を呼び起こします。新規ユーザーが入ってくると

システムにより、Chainlink ノードの実行による将来の潜在的な収益が増加します。 現在および将来のユーザーにとって経済的安全性の限界コストが低下します。の体制で 弾力的な需要により、このコストの減少により、追加のユーザーが ネットワークに接続し、継続的な好循環の中で継続的に導入を継続します。 注: このホワイトペーパーは、Chainlink の進化に関する私たちのビジョンの重要な要素を概説していますが、非公式であり、詳細な技術仕様はほとんど含まれていません。予定しています 進化に応じて、追加の機能とアプローチに焦点を当てた技術文書をリリースします。 さらに、ビジョンの多くの要素が提示されていることを強調することが重要です。 ここ（スケーリングの改善、機密性テクノロジー、FSS など）は可能ですし、そうなるでしょう。 高度な DON が基本機能になる前でも、暫定的な形式で導入されていました。 Chainlink。 1.3 この論文の構成 セクション 2 でセキュリティ モデルと表記法を示し、分散型セキュリティの概要を説明します。 Oracle Network API についてはセクション 3 で説明します。セクション 4 では、さまざまな例を示します。 DON が魅力的な展開プラットフォームを提供するアプリケーション。読者は次のことを行うことができます ここまで読んで、この論文の主要な概念のほとんどを学びましょう。 この文書の残りの部分には、さらなる詳細が記載されています。公平な順序付けについて説明します サービス (FSS) についてはセクション 5 で、トランザクション実行フレームワーク (TEF) についてはセクション 6 で説明します。信頼の最小化に対するアプローチについてはセクション 7 で説明します。 重要な DON 展開要件、つまり機能の増分ロールアウト、動的な台帳メンバーシップ、セクション 8 の説明責任。最後に、セクション 9 で次のことを示します。 インセンティブ設計に対する当社の開発アプローチの概要。セクション 10 で結論を述べます。 この文書の概念についてあまり詳しくない読者を助けるために、 付録 A に用語集を記載しています。DON インターフェイスについてさらに詳しく説明します。 とその機能については付録 B で説明し、アダプタの例を付録 C でいくつか示します。 付録 D では、信頼を最小限に抑えたデータ ソースの暗号化プリミティブについて説明します。 認証は関数署名と呼ばれ、離散化関数署名と呼ばれる新しいバリアントが導入されます。委員会に関するいくつかの考慮事項について議論します 付録 F の DON の選択。

Conceptual figure showing how DONs improve blockchain smart contract scaling by moving computation off-chain

Conceptual figure depicting on-chain and off-chain contract composition in a hybrid smart contract architecture

Mô hình và mục tiêu bảo mật

Mạng Oracle phi tập trung là một hệ thống phân tán riêng biệt mà chúng tôi mong đợi sẽ ban đầu được thực hiện một cách thông thường—mặc dù không nhất thiết—bởi một ủy ban giao thức đồng thuận và được điều hành bởi một tập hợp các nút oracle. DON được thiết kế chủ yếu để tăng cường khả năng của smart contract trên chuỗi chính với báo cáo oracle và các dịch vụ khác, nhưng nó có thể cung cấp các dịch vụ hỗ trợ tương tự cho các hệ thống không phảiblockchain khác và do đó không cần phải liên kết với một chuỗi chính cụ thể.

Do đó, mô hình và các đặc tính mà chúng tôi xem xét phần lớn độc lập với việc sử dụng các ứng dụng cụ thể của DON. 2.1 Mô hình kiến trúc hiện tại Điều quan trọng cần nhấn mạnh là Chainlink ngày nay không phải là một dịch vụ nguyên khối mà là một khuôn khổ không cần cấp phép trong đó có thể khởi chạy các ứng dụng độc lập, khác biệt mạng gồm oracle nút [77]. Mạng có tập hợp các toán tử nút không đồng nhất và thiết kế. Họ cũng có thể khác nhau về loại dịch vụ họ cung cấp, có thể bao gồm, ví dụ: nguồn cấp dữ liệu, Bằng chứng dự trữ, tính ngẫu nhiên có thể kiểm chứng, v.v. Khác sự khác biệt có thể bao gồm mức độ phân cấp, quy mô của mạng về mặt giá trị bị khóa mà nó hỗ trợ và các tham số cấp dịch vụ khác nhau, chẳng hạn như tần số dữ liệu và độ chính xác. Mô hình không được phép của Chainlink khuyến khích sự phát triển của một hệ sinh thái trong đó các nhà cung cấp chuyên về các dịch vụ mà họ có thể cung cấp tốt nhất cho cộng đồng. Cái này mô hình có khả năng mang lại chi phí thấp hơn cho người dùng và chất lượng dịch vụ cao hơn mô hình yêu cầu tất cả các nút và mạng cung cấp đầy đủ các dịch vụ, một cách tiếp cận có thể dễ dàng chuyển sang áp dụng trên toàn hệ thống các dịch vụ đại diện cho ít nhất mẫu số chung của tài nguyên có sẵn cho các nút. Khi Chainlink phát triển theo hướng thiết kế dựa trên DON trong Chainlink 2.0, chúng tôi tiếp tục hỗ trợ mô hình của một khuôn khổ mở, không được phép, theo dõi mục tiêu của cung cấp cho người dùng nhiều lựa chọn dịch vụ mang lại kết quả phù hợp nhất trên toàn cầu với các yêu cầu ứng dụng cụ thể. 2.2 Giả định đồng thuận Chúng tôi sử dụng thuật ngữ Mạng Oracle phi tập trung để bao gồm đầy đủ chức năng của hệ thống oracle mà chúng tôi mô tả: cả cấu trúc dữ liệu mà các nút oracle duy trì và API cốt lõi được xếp chồng lên trên nó. Chúng tôi sử dụng thuật ngữ sổ cái (chữ thường), ký hiệu là L, để chỉ dữ liệu cơ bản cấu trúc được duy trì bởi DON và được sử dụng để hỗ trợ các dịch vụ cụ thể mà nó cung cấp. Chúng tôi nhấn mạnh rằng khung DON của chúng tôi không coi L là một hệ thống độc lập như a blockchain: Mục đích của nó là hỗ trợ blockchains và các hệ thống khác. Blockchain là, tất nhiên, có một cách để tạo ra một sổ cái đáng tin cậy, nhưng vẫn có những cách khác. Chúng tôi mong đợi DONs trong nhiều trường hợp để nhận ra sổ cái cơ bản của họ bằng cách sử dụng Byzantine Fault Tolerant (BFT) hệ thống có trước đáng kể các hệ thống blockchain như Bitcoin [174]. Chúng tôi sử dụng BFT-loại ký hiệu và thuộc tính xuyên suốt bài viết để thuận tiện, mặc dù chúng tôi nhấn mạnh rằng DONs có thể được thực hiện bằng cách sử dụng các giao thức đồng thuận không được phép. Về mặt khái niệm, sổ cái L là một bảng thông báo trên đó dữ liệu được sắp xếp tuyến tính. Nhìn chung, chúng tôi xem sổ cái có một số thuộc tính chính thường được gán cho blockchains [115]. Một sổ cái là: • Chỉ nối thêm: Dữ liệu sau khi được thêm vào sẽ không thể bị xóa hoặc sửa đổi.• Công khai: Bất kỳ ai cũng có thể đọc được nội dung nhất quán theo thời gian trong chế độ xem của tất cả người dùng.4 • Có sẵn: Sổ cái luôn có thể được người viết được ủy quyền viết và đọc bởi bất cứ ai một cách kịp thời. Các thuộc tính thay thế có thể có trong sổ cái cho DON khi được nhận ra bởi một ủy ban. Ví dụ: quyền truy cập ghi sổ cái có thể bị hạn chế đối với một số người dùng nhất định, vì có thể truy cập đọc đối với một số ứng dụng, tức là sổ cái không cần phải công khai như được xác định ở trên. Tương tự, các quy tắc sổ cái có thể cho phép sửa đổi hoặc biên tập lại dữ liệu. Chúng tôi không Tuy nhiên, hãy xem xét rõ ràng các biến thể như vậy trong bài viết này. Thiết kế mô-đun của DON có thể hỗ trợ bất kỳ loại BFT hiện đại nào các giao thức, ví dụ: Hotstuff[231]. Sự lựa chọn chính xác sẽ phụ thuộc vào các giả định về độ tin cậy và đặc điểm mạng giữa các nút oracle. Về nguyên tắc, DON có thể thay thế sử dụng blockchain không được phép có hiệu suất cao cho sổ cái của nó với vai trò hỗ trợ hệ thống lớp 2 hoặc blockchain có khả năng mở rộng tương đương. Tương tự, sự lai tạo cũng có thể xảy ra: Về nguyên tắc, DON có thể bao gồm các nút là validator trong một mạng hiện có blockchain, ví dụ: trong hệ thống Bằng chứng cổ phần trong đó các ủy ban được chọn để thực thi giao dịch, ví dụ: [8, 81, 120, 146, 204]. Chế độ hoạt động đặc biệt này đòi hỏi các nút hoạt động theo cách sử dụng kép, tức là hoạt động cả dưới dạng nút blockchain và DON nút. (Xem Phần 8.2 để thảo luận về các kỹ thuật nhằm đảm bảo tính liên tục trong việc thay đổi ủy ban và Phụ lục F về một số lưu ý khi lựa chọn ủy ban ngẫu nhiên.) Trong thực tế, trong thuật toán BFT hiện đại, các nút ký điện tử vào các thông báo trên sổ cái. Chúng ta giả sử để thuận tiện rằng L có một khóa công khai pkL liên quan và nội dung của nó được ký bởi khóa riêng tương ứng. Ký hiệu chung này áp dụng ngay cả khi dữ liệu trên L được ký bằng chữ ký ngưỡng.5 Chữ ký ngưỡng rất thuận tiện, vì chúng kích hoạt danh tính lâu dài cho DON ngay cả khi thay đổi tư cách thành viên trong các nút đang chạy nó. (Xem Phụ lục B.1.3.) Do đó, chúng tôi giả định rằng skL được chia sẻ bí mật theo cách ngưỡng (k, n) đối với một số tham số an toàn k, ví dụ: k = 2f + 1 và n = 3f + 1, trong đó f là số nút có khả năng bị lỗi. (Bằng cách chọn k ở đây theo cách này, chúng tôi đảm bảo rằng các nút bị lỗi không thể học skL cũng như không thể thực hiện việc từ chối dịch vụ cuộc tấn công ngăn chặn việc sử dụng nó.) Một thông báo trên L có dạng M = (m, z), trong đó m là một chuỗi và z là duy nhất số chỉ mục tuần tự. Nếu có thể, chúng ta viết tin nhắn dưới dạng m = ⟨MessageType : tải trọng⟩. Loại thông báo MessageType là cú pháp cho biết chức năng của một thông báo cụ thể. 4Trong trường hợp blockchain không có số cuối cùng nhận ra một sổ cái, sự không nhất quán thường bị loại trừ tránh xa bằng cách bỏ qua các khối không đủ sâu hoặc “cắt tỉa” [115]. 5Trong thực tế, một số cơ sở mã, ví dụ: LibraBFT [205], một biến thể của Hotstuff, hiện đã áp dụng đa chữ ký, thay vì chữ ký ngưỡng, giảm bớt độ phức tạp trong giao tiếp cho kỹ thuật đơn giản hơn. Với một số chi phí bổ sung, các nút oracle có thể thêm chữ ký ngưỡng vào tin nhắn được ghi vào L ngay cả khi giao thức đồng thuận được sử dụng cho L không sử dụng chúng.2.3 Ký hiệu Chúng ta biểu thị tập hợp n oracle nút chạy sổ cái bằng O = {Oi}n tôi = 1. Như vậy tập hợp các nút thường được gọi là một ủy ban. Để đơn giản, chúng ta giả sử rằng tập hợp oracle đang triển khai chức năng DON, tức là các dịch vụ trên L, giống hệt với duy trì L, nhưng chúng có thể khác biệt. Chúng ta đặt pki biểu thị khóa công khai của người chơi Oi và trượt khóa riêng tương ứng. Hầu hết các thuật toán BFT yêu cầu ít nhất n = 3f + 1 nút, trong đó f là số lượng các nút có khả năng bị lỗi; các nút còn lại là trung thực, theo nghĩa là chúng tuân theo giao thức chính xác như được chỉ định. Chúng tôi coi ủy ban O là trung thực nếu nó đáp ứng được điều này yêu cầu, tức là có nhiều hơn 2/3 số nút trung thực. Trừ khi có cách khác đã nêu, chúng tôi cho rằng O là trung thực (và là một mô hình tham nhũng tĩnh). Chúng tôi sử dụng pkO / skO có thể hoán đổi cho nhau bằng pkL / skL, tùy theo ngữ cảnh. Chúng ta đặt σ = Sigpk[m] biểu thị chữ ký trên thông báo m đối với pk, tức là sử dụng sk khóa riêng tương ứng. Đặt verify(pk, σ, m) →{false, true} biểu thị thuật toán xác minh chữ ký tương ứng. (Chúng tôi ngầm định việc tạo khóa trong suốt bài viết.) Chúng tôi sử dụng ký hiệu S để biểu thị nguồn dữ liệu và S để biểu thị toàn bộ nguồn nS trong một bối cảnh nhất định. Chúng tôi biểu thị bằng MAINCHAIN một hợp đồng thông minh được kích hoạt blockchain được hỗ trợ bởi DON. Chúng tôi sử dụng thuật ngữ hợp đồng dựa trên để biểu thị bất kỳ thông minh nào hợp đồng trên MAINCHAIN giao tiếp với DON và sử dụng ký hiệu SC để biểu thị một hợp đồng như vậy. Chúng tôi thường giả định rằng DON hỗ trợ một MAINCHAIN chuỗi chính duy nhất, mặc dù nó có thể hỗ trợ nhiều chuỗi như vậy, như chúng tôi trình bày trong các ví dụ ở Phần 4. A DON có thể và thường sẽ hỗ trợ nhiều hợp đồng dựa trên MAINCHAIN. (Như đã lưu ý ở trên, DON có thể hỗ trợ các dịch vụ không phải blockchain.) 2.4 Lưu ý về Mô hình Tin cậy Như đã lưu ý ở trên, DON có thể được xây dựng dựa trên các giao thức đồng thuận dựa trên ủy ban và chúng tôi mong đợi họ sẽ thường xuyên sử dụng các giao thức như vậy. Có nhiều lập luận mạnh mẽ cho rằng một trong hai lựa chọn thay thế, blockchain dựa trên ủy ban hoặc không được phép, cung cấp bảo mật mạnh hơn cái kia. Điều quan trọng là phải nhận ra rằng tính bảo mật của dựa trên ủy ban và không được phép hệ thống phi tập trung là không thể so sánh được. Thỏa hiệp PoW hoặc PoS blockchain thông qua tấn công 51% yêu cầu đối thủ phải có được phần lớn tài nguyên một cách nhất thời và có khả năng ẩn danh, chẳng hạn như bằng cách thuê nguồn điện hash trong hệ thống PoW. Như vậy các cuộc tấn công trong thực tế đã ảnh hưởng đến một số blockchains [200, 34]. Ngược lại, xâm phạm một hệ thống dựa trên ủy ban có nghĩa là làm hỏng một số ngưỡng (thường là một phần ba) các nút của nó, trong đó các nút có thể được biết đến công khai, có nguồn lực tốt, và các đơn vị đáng tin cậy. Mặt khác, các hệ thống dựa trên ủy ban (cũng như các hệ thống không cần cấp phép “kết hợp” hệ thống hỗ trợ các ủy ban) có thể hỗ trợ nhiều chức năng hơn so vớicác hệ thống phi nhiệm vụ. Điều này bao gồm khả năng duy trì các bí mật lâu dài, chẳng hạn như khóa ký và/hoặc mã hóa—một khả năng trong thiết kế của chúng tôi. Chúng tôi nhấn mạnh rằng DON về nguyên tắc có thể được xây dựng trên nền tảng dựa trên ủy ban hoặc giao thức đồng thuận không được phép và DON người triển khai cuối cùng có thể chọn áp dụng một trong hai cách tiếp cận. Củng cố các mô hình niềm tin: Tính năng chính của Chainlink ngày nay là khả năng người dùng chọn các nút dựa trên các bản ghi phi tập trung về lịch sử hiệu suất của chúng, như đã thảo luận ở Mục 3.6.4. Cơ chế staking và Khung khuyến khích ngầm định mà chúng tôi giới thiệu trong Phần 9 cùng nhau tạo thành một thiết kế cơ chế nghiêm ngặt và có phạm vi rộng khuôn khổ sẽ trao quyền cho người dùng khả năng mở rộng đáng kể để đánh giá tính bảo mật của DONs. Khung tương tự này cũng sẽ giúp chính DONs có thể thực hiện được để thực thi các yêu cầu bảo mật khác nhau trên các nút tham gia và đảm bảo hoạt động trong các mô hình niềm tin mạnh mẽ. Cũng có thể sử dụng các công cụ được mô tả trong bài viết này cho DON để thực thi các yêu cầu về mô hình tin cậy đặc biệt, chẳng hạn như tuân thủ các yêu cầu quy định. cho Ví dụ, bằng cách sử dụng các kỹ thuật được thảo luận trong Phần 4.3, các nút có thể đưa ra bằng chứng về các đặc điểm của nhà điều hành nút, ví dụ: lãnh thổ hoạt động, có thể được sử dụng để trợ giúp thực thi việc tuân thủ, ví dụ: Quy định chung về bảo vệ dữ liệu (GDPR) Điều 3 (“Phạm vi lãnh thổ”) [105]. Việc tuân thủ như vậy có thể là thách thức đối với gặp nhau trong các hệ thống phi tập trung [45]. Ngoài ra, trong Phần 7, chúng tôi thảo luận về kế hoạch tăng cường độ bền của DONs thông qua các cơ chế giảm thiểu niềm tin trên các chuỗi chính mà họ hỗ trợ.

セキュリティモデルと目標

分散型 Oracle ネットワークは、私たちが期待する独特の分散システムです。 必ずしもではありませんが、最初は通常、委員会ベースで実装されます。 コンセンサス プロトコルを使用し、oracle ノードのセットによって実行されます。 DON は主に設計されています oracle レポートを使用して、メイン チェーン上の smart contract の機能を強化します。 および他のサービスですが、同じサポート サービスを他の非blockchain システムに提供できるため、特定のメイン チェーンに関連付ける必要はありません。

したがって、私たちが考慮するモデルとプロパティは、 DON の特定の用途。 2.1 現在の建築モデル 現在の Chainlink はモノリシック サービスではなく、 個別の独立したプログラムを起動できる許可のないフレームワーク oracle ノード [77] のネットワーク。ネットワークには異種のノード オペレーターのセットがあり、 デザイン。また、提供するサービスの種類も異なる場合があります。 これには、データフィード、プルーフオブリザーブ、検証可能なランダム性などが含まれます。その他 違いには、分散化の程度、ネットワークのサイズなどが含まれます。 サポートするロック値、およびデータ頻度などのさまざまなサービスレベルパラメータ そして正確さ。 Chainlink のパーミッションレス モデルは、エコシステムの成長を促進します。 プロバイダーは、コミュニティに提供できる最善のサービスを専門としています。これ モデルは、モデルよりもユーザーのコストが低くなり、サービス品質が高くなる可能性があります すべてのノードとネットワークがあらゆる種類のサービスを提供する必要があるというアプローチ これは、最も少ないサービスのシステム全体への導入に容易に発展する可能性があります。 ノードが利用できるリソースの共通分母。 Chainlink が Chainlink 2.0 の DON ベースの設計に向けて進化するにつれて、私たちは引き続き という目標を念頭に置きながら、パーミッションレスでオープンなフレームワークのモデルをサポートします。 グローバルに最適な結果となる幅広いサービスの選択肢をユーザーに提供します 特定のアプリケーション要件を備えています。 2.2 コンセンサスの仮定 私たちは、分散型 Oracle ネットワークという用語を、次のすべての機能を包含するために使用します。 私たちが説明する oracle システム: oracle ノードが維持するデータ構造と その上にコア API が重ねられます。 基になるデータを意味するために、L で示されるレジャー (小文字) という用語を使用します。 DON によって維持され、それが提供する特定のサービスをサポートするために使用される構造。 私たちの DON フレームワークは L を次のような独立したシステムとして扱っていないことを強調します。 a blockchain: その目的は、blockchains およびその他のシステムをサポートすることです。ブロックチェーンとは、 もちろん、これは信頼できる台帳を実現する 1 つの方法ですが、他にも方法があります。期待しています DONs は多くの場合、ビザンチン フォールト トレラントを使用して基礎となる台帳を実現します。 (BFT) システム。Bitcoin [174] など、blockchain よりかなり古いものです。私たちが使用するのは 便宜上、BFT タイプの表記とプロパティを本書全体で使用していますが、 DONs はパーミッションレス コンセンサス プロトコルを使用して実現できることを強調します。 概念的には、台帳 L は、データが線形に順序付けされている掲示板です。 私たちは一般的に台帳には、一般的に考えられるいくつかの重要なプロパティがあると考えています。 blockchains [115]。台帳とは次のとおりです。 • 追加のみ: データは一度追加すると、削除したり変更したりすることはできません。• パブリック: 誰でもその内容を読むことができ、その内容は時代を超えて一貫しています。 すべてのユーザーのビュー。4 • 利用可能: レジャーは、許可された書き込み者によって常に書き込みおよび読み取りが可能です。 誰でもタイムリーに。 DON によって実現される場合、台帳内で代替プロパティが可能になります。 委員会。たとえば、台帳への書き込みアクセスは、次のように特定のユーザーに制限される場合があります。 一部のアプリケーションには読み取りアクセスが許可される場合があります。つまり、台帳は定義どおりに公開される必要はありません。 上。同様に、元帳ルールではデータの変更または編集が許可される場合があります。しません ただし、この論文ではそのようなバリアントを明示的に考慮します。 DON のモジュラー設計は、さまざまな最新の BFT をサポートできます。 プロトコル（例: Hotstuff[231]）。正確な選択は信頼の前提条件と oracle ノード間のネットワーク特性。 DON は原則として代わりに行うことができます をサポートする役割の台帳には、高パフォーマンスの権限のない blockchain を使用します。 同様にスケーラブルなレイヤー 2 または blockchain システム。同様に、ハイブリダイゼーションも可能です。 DON は、原則として、既存の validator であるノードで構成されます。 blockchain、例: 実行する委員会が選択されるプルーフ・オブ・ステーク システム トランザクション、例: [8, 81, 120, 146, 204]。この特定の動作モードでは、次のことが必要です。 ノードはデュアルユース方式で動作します。つまり、blockchain ノードと DON の両方として動作します。 ノード。 (変更の継続性を確保するための手法については、セクション 8.2 を参照してください) 委員会のランダムな選択に関するいくつかの注意事項については、委員会および付録 F を参照してください。) 実際には、最新の BFT アルゴリズムでは、ノードは台帳上のメッセージにデジタル署名します。 便宜上、L には関連する公開鍵 pkL があり、その内容は 対応する秘密鍵によって署名されます。この一般的な表記は、次の場合にも適用されます。 L 上のデータは、しきい値署名を使用して署名されます。5 しきい値署名は便利です。 メンバーシップが変更された場合でも、DON の永続的な ID が有効になるためです。 それを実行しているノード。 (付録 B.1.3 を参照。) したがって、skL は秘密共有されていると仮定します。 あるセキュリティパラメータ k に対して (k, n) しきい値方式で、たとえば k = 2f + 1 および n = 3f + 1、ここで f は障害のある可能性のあるノードの数です。 (ここで k を選択すると、 このようにして、障害のあるノードが skL を学習したり、サービス妨害をマウントしたりできないようにします。 攻撃により使用が妨げられます。) L 上のメッセージは M = (m, z) の形式をとります。ここで、m は文字列、z は一意です。 連続したインデックス番号。 該当する場合、メッセージは m = の形式で記述されます。 ⟨メッセージタイプ:ペイロード⟩。メッセージ タイプ MessageType は、特定のメッセージの機能を示す糖衣構文です。 4 ファイナリティのないblockchainが元帳を実現する場合、通常、不整合は抽象化されます。 深さが不十分なブロックを無視するか、[115] を「枝刈り」することによって除去します。 5実際には、Hotstuff の亜種である LibraBFT [205] などの一部のコード ベースが現在採用しています。 しきい値署名ではなくマルチ署名により、通信の複雑さが軽減されます。 よりシンプルなエンジニアリング。コストを追加すると、oracle ノードはメッセージにしきい値署名を追加できます L に使用されるコンセンサス プロトコルがそれらを採用していない場合でも、L に書き込まれます。2.3 表記 台帳を実行する n 個の oracle ノードのセットを O = {Oi}n で表します。 i=1。 そんな ノードのセットは委員会と呼ばれることがよくあります。簡単にするために、次のセットがあると仮定します。 oracles の DON 機能、つまり L 上のサービスの実装は、 L は維持されますが、異なる場合もあります。 pki に次の公開鍵を示します。 プレーヤー Oi を取得し、対応する秘密鍵をスキーします。 ほとんどの BFT アルゴリズムでは、少なくとも n = 3f + 1 ノードが必要です。ここで、f はノードの数です。 潜在的に障害のあるノード。残りのノードは、以下に従うという意味で正直です。 プロトコルは指定どおりに実行されます。これを満たしている場合、委員会 O は誠実であるとみなします。 つまり、正直なノードの 2/3 部分を超えています。そうでない限り 前述したように、O は正直である (そして腐敗の静的モデルである) と仮定します。 pkO / を使用します。 skO は、文脈に応じて pkL / skL と同じ意味です。 σ = Sigpk[m] が pk に関するメッセージ m の署名を表すものとします。つまり、以下を使用します。 対応する秘密鍵 sk. verify(pk, σ, m) →{false, true} が対応する署名検証アルゴリズムを表すものとします。 (本稿では鍵の生成を暗黙的に残しておきます。) データ ソースを表すには S という表記を使用し、データ ソースの完全なセットを表すには S を使用します。 特定のコンテキスト内の nS ソース。 MAINCHAIN はスマートコントラクトが有効であることを示します blockchain は DON によってサポートされています。私たちは、信頼できるコントラクトという用語を、あらゆるスマートなサービスを表すために使用します。 DON と通信する MAINCHAIN 上のコントラクトを作成し、SC という表記を使用して そのような契約を指します。 セクション 4 の例で示すように、DON は単一のメイン チェーン MAINCHAIN をサポートすると想定していますが、複数のそのようなチェーンをサポートすることもできます。 DON は、MAINCHAIN で複数の依存コントラクトをサポートできますし、通常はサポートします。 (として 前述のように、DON は、blockchain 以外のサービスをサポートすることもできます。) 2.4 信頼モデルに関する注意事項 上で述べたように、DON は委員会ベースのコンセンサス プロトコルの上に構築される場合があります。 彼らはそのようなプロトコルを一般的に使用すると予想されます。多くの有力な議論がありますが、 2 つの選択肢 (委員会ベースまたは権限のない blockchain) のいずれかにより、以下が提供されます。 他よりも強力なセキュリティ。 委員会ベースとパーミッションレスのセキュリティは重要であることを認識することが重要です。 分散型システムは計り知れないものです。 PoW または PoS の侵害 blockchain via 51% 攻撃では、敵が過半数のリソースを一時的に取得する必要があり、 たとえば、PoW システムで hash 電力を借りるなど、潜在的に匿名で行われます。そんな 実際の攻撃はすでにいくつかのblockchainに影響を与えています[200、34]。対照的に、 委員会ベースのシステムを侵害するということは、ノードが公に知られ、十分なリソースがあり、 そして信頼できる存在。 一方、委員会ベースのシステム（および「ハイブリッド」パーミッションレス） 委員会をサポートするシステム）は、厳密に定義されている機能よりも多くの機能をサポートできます。ミッションレスシステム。これには、次のような永続的な秘密を維持する機能が含まれます。 署名キーや暗号化キー - 私たちの設計における可能性の 1 つです。 DON は原則として委員会ベースの、または パーミッションレスコンセンサスプロトコルと DON デプロイ担当者は最終的に採用を選択する可能性があります どちらかのアプローチ。 信頼モデルの強化: 現在の Chainlink の重要な機能は、ユーザーが次のことを実行できることです。 説明したように、パフォーマンス履歴の分散記録に基づいてノードを選択します。 セクション3.6.4に記載されています。セクション 9 で紹介する staking メカニズムと暗黙的インセンティブ フレームワークは合わせて、広範囲にわたる厳密なメカニズム設計を構成します。 このフレームワークにより、ユーザーは DON のセキュリティを評価できる機能が大幅に拡張されます。これと同じフレームワークにより、DON 自体も可能になります。 参加ノードにさまざまなセキュリティ要件を強制し、動作を保証するため 強力な信頼モデル内で。 このペーパーで説明されている DON のツールを使用して、規制要件への準拠など、特別な信頼モデル要件を強制することもできます。のために たとえば、セクション 4.3 で説明した手法を使用すると、ノードは次の証拠を提示できます。 ノードとオペレーターの特性 (例: 運用地域など)。 たとえば、一般データ保護規則 (GDPR) 第 3 条 (「適用範囲」) [105] への準拠を強制します。そうでなければ、このようなコンプライアンスは困難になる可能性があります 分散システム [45] で会います。 さらに、セクション 7 では、DON の堅牢性を強化する計画について説明します。 サポートするメインチェーンの信頼最小化メカニズムを通じて。

Giao diện mạng Oracle phi tập trung và Ca-

khả năng Ở đây chúng tôi phác thảo ngắn gọn các khả năng của DON theo cách đơn giản nhưng mạnh mẽ giao diện mà chúng được thiết kế để hiện thực hóa. Các ứng dụng trên DON bao gồm các tệp thực thi và bộ điều hợp. Một tệp thực thi là một chương trình có logic cốt lõi là chương trình xác định, tương tự như smart contract. Một tệp thực thi cũng có một số bộ khởi tạo đi kèm, các chương trình gọi mục nhập chỉ vào logic của tệp thực thi khi xảy ra các sự kiện được xác định trước—ví dụ: tại một số thời điểm nhất định (như công việc định kỳ), khi giá vượt qua một ngưỡng, v.v.—giống như Người giữ (xem Phần 3.6.3). Bộ điều hợp cung cấp giao diện cho các tài nguyên ngoài chuỗi và có thể được gọi bởi hoặc là bộ khởi tạo hoặc logic cốt lõi trong các tệp thực thi. Vì hành vi của họ có thể phụ thuộc vào điều đó của các tài nguyên bên ngoài, bộ khởi tạo và bộ điều hợp có thể hoạt động không mang tính xác định. Chúng tôi mô tả giao diện nhà phát triển DON cũng như chức năng của các tệp thực thi và bộ điều hợp theo ba tài nguyên thường được sử dụng để mô tả các hệ thống máy tính: mạng, tính toán và lưu trữ. Chúng tôi cung cấp một cái nhìn tổng quan ngắn gọn về mỗi trong số này các nguồn bên dưới và cung cấp thêm chi tiết trong Phụ lục B.

Adapters connecting a DON with different resources including blockchains, web servers, storage, and IoT devices

3.1 Mạng Bộ điều hợp là các giao diện mà qua đó các tệp thực thi chạy trên DON có thể gửi và nhận dữ liệu từ hệ thống off-DON. Bộ điều hợp có thể được xem như là sự khái quát hóa của các bộ chuyển đổi được sử dụng trong Chainlink hôm nay [20]. Bộ điều hợp có thể là hai chiều—tức là chúng không thể chỉ kéo mà còn đẩy dữ liệu từ DON tới máy chủ web. Họ cũng có thể tận dụng các giao thức phân tán cũng như chức năng mã hóa như bảo mật đa bên tính toán. Hình 9: Bộ điều hợp kết nối DON, ký hiệu là DON1, với nhiều loại tài nguyên khác nhau, bao gồm một DON khác, ký hiệu là DON2, blockchain (chuỗi chính) và của nó mempool, bộ nhớ ngoài, máy chủ web và thiết bị IoT (thông qua máy chủ web). Ví dụ về các tài nguyên bên ngoài mà bộ điều hợp có thể được tạo được hiển thị trong Hình 9. Chúng bao gồm: • Chuỗi khối: Bộ chuyển đổi có thể xác định cách gửi giao dịch tới blockchain và cách đọc các khối, giao dịch riêng lẻ hoặc trạng thái khác từ nó. Một bộ chuyển đổi cũng có thể được xác định cho mempool của blockchain. (Xem Phần 3.5.) • Máy chủ web: Bộ điều hợp có thể xác định API thông qua đó dữ liệu có thể được truy xuất từ các máy chủ web, bao gồm cả các hệ thống cũ không được điều chỉnh đặc biệt cho giao tiếp với DONs. Các bộ điều hợp như vậy cũng có thể bao gồm các API để gửi dữ liệu tới những máy chủ như vậy. Các máy chủ web mà DON kết nối có thể đóng vai trò là cổng tới các tài nguyên bổ sung, chẳng hạn như các thiết bị Internet-of-Things (IoT).• Bộ nhớ ngoài: Bộ điều hợp có thể xác định các phương thức đọc và ghi vào bộ lưu trữ dịch vụ bên ngoài DON, chẳng hạn như hệ thống tệp phi tập trung [40, 188] hoặc đám mây lưu trữ. • Các DON khác: Bộ điều hợp có thể truy xuất và truyền dữ liệu giữa DON. Chúng tôi hy vọng rằng việc triển khai ban đầu DON sẽ bao gồm một tập hợp các khối xây dựng bộ điều hợp cho các tài nguyên bên ngoài được sử dụng phổ biến như vậy và sẽ tiếp tục cho phép DON-cụ thể bộ điều hợp sẽ được xuất bản bởi nút DON. Khi smart contract nhà phát triển viết bộ điều hợp hôm nay, chúng tôi hy vọng rằng họ sẽ xây dựng các bộ điều hợp mạnh mẽ hơn nữa bằng cách sử dụng công cụ nâng cao này chức năng. Chúng tôi hy vọng rằng cuối cùng người dùng sẽ có thể tạo các bộ điều hợp mới theo cách cách không được phép. Một số bộ điều hợp phải được xây dựng theo cách đảm bảo tính ổn định và sẵn có của các tài nguyên bên ngoài do DON kiểm soát. Ví dụ: lưu trữ đám mây có thể yêu cầu duy trì tài khoản dịch vụ đám mây. Ngoài ra, DON có thể thực hiện quản lý phi tập trung các khóa riêng thay mặt cho người dùng (như trong, ví dụ: [160]) và/hoặc thực thi. Do đó, DON có khả năng kiểm soát các tài nguyên, chẳng hạn như tiền điện tử, có thể được sử dụng, ví dụ: để gửi giao dịch trên mục tiêu blockchain. Xem Phụ lục B.1 để biết thêm chi tiết về bộ điều hợp DON, như Phụ lục C cho một số bộ điều hợp bộ điều hợp ví dụ. 3.2 tính toán Tệp thực thi là đơn vị mã cơ bản trên DON. Một tệp thực thi là một cặp exec = (lôgic, khởi tạo). Ở đây, logic là một chương trình xác định với một số mục được chỉ định các điểm (logic1, logic2, . . . , logicℓ) và init là tập hợp các điểm khởi tạo tương ứng (init1, init2,..., inite). Để đảm bảo khả năng kiểm tra đầy đủ của DON, logic của tệp thực thi sử dụng sổ cái cơ bản L cho tất cả các đầu vào và đầu ra. Vì vậy, ví dụ, bất kỳ bộ chuyển đổi nào dữ liệu phục vụ làm đầu vào cho một tệp thực thi phải được lưu trữ trước tiên trên L. Người khởi xướng: Những người khởi tạo trong Chainlink hôm nay thực hiện các công việc phụ thuộc vào sự kiện trên Chainlink nút [21]. Các bộ khởi tạo trong DONs hoạt động theo cách tương tự. Tuy nhiên, trình khởi tạo DON được liên kết cụ thể với một tệp thực thi. Người khởi xướng có thể phụ thuộc trên một sự kiện hoặc trạng thái bên ngoài, vào thời điểm hiện tại hoặc trên một vị từ trên trạng thái DON. Với sự phụ thuộc vào các sự kiện, những người khởi xướng tất nhiên có thể hành xử không mang tính xác định. (tất nhiên là có thể có bộ điều hợp). Trình khởi tạo có thể thực thi trong các nút DON riêng lẻ và do đó không cần phải dựa vào bộ chuyển đổi. (Xem ví dụ 1 bên dưới.) Trình khởi tạo là một tính năng quan trọng để phân biệt các tệp thực thi với smart contracts. Bởi vì một tập tin thực thi có thể chạy để phản hồi lại một bộ khởi tạo nên nó có thể hoạt động một cách hiệu quả. một cách tự chủ, tất nhiên bằng cách mở rộng, một hợp đồng kết hợp có thể kết hợp với tệp thực thi. Một dạng người khởi xướng hiện nay là Chainlink Người giữ, cung cấp giao dịchdịch vụ tự động hóa, kích hoạt smart contract thực thi—chẳng hạn như thanh lý các khoản vay không được thế chấp và thực hiện các giao dịch theo lệnh giới hạn—dựa trên báo cáo oracle. Thuận tiện, những người khởi xướng trong DON cũng có thể được xem như một cách chỉ định các thỏa thuận dịch vụ áp dụng cho một tệp thực thi, vì chúng xác định các trường hợp theo mà DON phải gọi nó. Ví dụ sau minh họa cách hoạt động của các trình khởi tạo trong một tệp thực thi: Ví dụ 1 (Nguồn cấp giá kích hoạt sai lệch). smart contract SC có thể yêu cầu mới dữ liệu nguồn cấp giá (xem Phần 3.6.3) bất cứ khi nào có thay đổi đáng kể, ví dụ: 1%, trong tỷ giá hối đoái giữa một cặp tài sản, ví dụ: ETH-USD. Giá nhạy cảm với biến động nguồn cấp dữ liệu được hỗ trợ trong Chainlink ngày hôm nay nhưng sẽ mang tính hướng dẫn để xem chúng có thể hoạt động như thế nào được thực hiện trên DON bằng nguồn cấp dữ liệu thực thi. Nguồn cấp dữ liệu thực thi duy trì giá ETH-USD gần đây nhất r trên L, trong dạng một chuỗi gồm ⟨NewPrice : j, r⟩entries, trong đó j là chỉ số tăng theo mỗi lần cập nhật giá. Trình khởi tạo init1 khiến mỗi nút Oi theo dõi giá ETH-USD hiện tại cho sai lệch ít nhất 1% so với giá lưu trữ gần đây nhất r với chỉ số j. Khi phát hiện ra sự sai lệch như vậy, Oi viết quan điểm hiện tại của mình về giá mới vào L bằng cách sử dụng mục nhập có dạng ⟨PriceView : i, j + 1, ri⟩. Trình khởi tạo thứ hai init2 kích hoạt khi có ít nhất k mục nhập PriceView như vậy với giá mới các giá trị cho chỉ mục j + 1 được tạo bởi các nút riêng biệt đã tích lũy trên L. Sau đó, init2 gọi một điểm vào logic2 để tính trung bình ρ của k giá trị xem giá hợp lệ, mới đầu tiên và ghi một giá trị mới ⟨NewPrice : j + 1, ρ⟩to L . (Về mặt hoạt động, các nút có thể thay phiên nhau làm người viết được chỉ định.) Trình khởi tạo thứ ba init3 theo dõi các mục NewPrice trên L. Bất cứ khi nào có báo cáo mới ⟨NewPrice : j, r⟩xuất hiện ở đó, nó gọi một điểm vào logic3 đẩy (j, r) tới SC sử dụng một bộ chuyển đổi. Như chúng tôi đã lưu ý, một tệp thực thi có khả năng tương tự như smart contract. Tuy nhiên, ngoài hiệu suất cao hơn, nó khác với hợp đồng chuỗi chính điển hình theo hai cách thiết yếu: 1. Tính bảo mật: Một tệp thực thi có thể thực hiện tính toán bí mật, tức là một chương trình bí mật có thể xử lý các đầu vào văn bản rõ ràng hoặc một chương trình đã xuất bản có thể xử lý dữ liệu đầu vào bí mật hoặc kết hợp cả hai. Trong một mô hình đơn giản, dữ liệu bí mật có thể được truy cập bởi các nút DON, nút này che giấu các kết quả trung gian và chỉ tiết lộ các giá trị được xử lý và khử trùng vào MAINCHAIN. Cũng có thể che giấu dữ liệu nhạy cảm khỏi chính DON: DON nhằm hỗ trợ các phương pháp tiếp cận như dưới dạng tính toán nhiều bên, ví dụ: [42, 157] và môi trường thực thi đáng tin cậy (TEE) [84, 133, 152, 229] cho mục đích này.6 6Bằng tiện ích mở rộng, cũng có thể giữ bí mật các tệp thực thi đối với các nút DON, mặc dù ngày nay điều này chỉ thực tế đối với các tệp thực thi không tầm thường sử dụng TEE.2. Vai trò hỗ trợ: Một tệp thực thi có nghĩa là hỗ trợ smart contract trên main chuỗi, thay vì thay thế chúng. Một tệp thực thi có một số hạn chế mà một smart contract không: (a) Mô hình tin cậy: Một tệp thực thi hoạt động trong mô hình tin cậy được xác định bởi DON: Việc thực thi chính xác dựa vào hành vi trung thực của O. (A main Tuy nhiên, chuỗi có thể cung cấp một số biện pháp bảo vệ chống lại sự cố DON, như được thảo luận trong Phần 7.3.) (b) Quyền truy cập tài sản: DON có thể kiểm soát tài khoản trên blockchain—và do đó kiểm soát tài sản trên đó thông qua một bộ chuyển đổi. Nhưng DON không thể có thẩm quyền đại diện cho các tài sản được tạo trên chuỗi chính, ví dụ: Ether hoặc ERC20 tokens, vì chuỗi gốc của họ duy trì hồ sơ có thẩm quyền về quyền sở hữu của họ. (c) Vòng đời: DON có thể được thiết lập có chủ ý với thời gian tồn tại giới hạn, vì được xác định bởi các thỏa thuận cấp độ dịch vụ trên chuỗi giữa DONs và chủ sở hữu dựa vào các hợp đồng. Ngược lại, chuỗi khối có nghĩa là hoạt động như hệ thống lưu trữ cố định. Xem Phụ lục B.2 để biết thêm chi tiết về tính toán DON. 3.3 Lưu trữ Là một hệ thống dựa trên ủy ban, DON có thể lưu trữ lượng dữ liệu vừa phải một cách liên tục trên L với chi phí thấp hơn nhiều so với blockchain không được phép. Ngoài ra, thông qua bộ điều hợp, DONs có thể tham chiếu các hệ thống phi tập trung bên ngoài để lưu trữ dữ liệu, ví dụ: Filecoin [85], và do đó có thể kết nối các hệ thống đó với smart contracts. Tùy chọn này đặc biệt hấp dẫn đối với dữ liệu số lượng lớn như một phương tiện giải quyết vấn đề phổ biến về “sự phình to” trong blockchain hệ thống. DONs do đó có thể lưu trữ dữ liệu cục bộ hoặc bên ngoài để sử dụng trong các dịch vụ được hỗ trợ cụ thể của chúng. DON cũng có thể sử dụng dữ liệu đó theo cách bí mật, tính toán trên dữ liệu: (1) được chia sẻ bí mật trên DON nút hoặc được mã hóa theo khóa được quản lý bởi các nút DON theo cách phù hợp để tính toán an toàn cho nhiều bên hoặc mã hóa đồng cấu một phần hoặc toàn bộ; hoặc (2) được bảo vệ bằng cách thực thi đáng tin cậy môi trường. Chúng tôi hy vọng rằng DONs sẽ áp dụng mô hình quản lý bộ nhớ đơn giản phổ biến cho hệ thống hợp đồng thông minh: Một tệp thực thi chỉ có thể ghi vào bộ nhớ của chính nó. Thực thi tuy nhiên, có thể đọc từ bộ nhớ của các tệp thực thi khác. Xem Phụ lục B.3 để biết thêm chi tiết về bộ lưu trữ DON. 3,4 Khung thực thi giao dịch (TEF) DON nhằm mục đích hỗ trợ các hợp đồng trên chuỗi chính MAINCHAIN (hoặc trên nhiều chuỗi chính). Khung thực thi giao dịch (TEF), được thảo luận chi tiếttrong Phần 6, là một cách tiếp cận có mục đích chung để thực hiện hợp đồng một cách hiệu quả SC trên MAINCHAIN và DON. TEF nhằm hỗ trợ FSS và lớp 2 công nghệ—đồng thời, nếu muốn. Thật vậy, nó có khả năng đóng vai trò là phương tiện chính để sử dụng FSS (và vì lý do đó, chúng tôi không thảo luận thêm về FSS trong phần này). Tóm lại, trong TEF, hợp đồng mục tiêu ban đầu được SC thiết kế hoặc phát triển cho MAINCHAIN được tái cấu trúc thành một hợp đồng lai. Việc tái cấu trúc này tạo ra hai khả năng tương tác các phần của hợp đồng kết hợp: hợp đồng MAINCHAIN SCa mà chúng tôi đề cập đến để hiểu rõ hơn trong bối cảnh TEF dưới dạng hợp đồng cố định và người thực thi có thể thực thi trên DON. các hợp đồng SCa giám sát tài sản của người dùng, thực hiện chuyển đổi trạng thái có thẩm quyền, đồng thời cung cấp các thanh chắn bảo vệ (xem Phần 7.3) chống lại các hư hỏng trong DON. Các nhà thực thi thực thi sắp xếp các giao dịch và cung cấp dữ liệu oracle liên quan cho chúng. Nó có thể bó giao dịch cho SCa theo bất kỳ cách nào—ví dụ: sử dụng dựa trên bằng chứng xác thực hoặc lạc quan rollups, thực thi bí mật bởi DON, v.v. Chúng tôi mong muốn phát triển các công cụ giúp nhà phát triển dễ dàng phân chia hợp đồng SC được viết bằng ngôn ngữ cấp cao thành các phần logic MAINCHAIN và DON, SCa và thực thi tương ứng, soạn thảo một cách an toàn và hiệu quả. Sử dụng TEF để tích hợp các sơ đồ giao dịch hiệu suất cao với các chương trình hiệu suất cao oracles là không thể thiếu đối với phương pháp mở rộng quy mô oracle của chúng tôi. 3,5 Dịch vụ Mempool Một tính năng quan trọng của lớp ứng dụng mà chúng tôi dự định triển khai trên DON để hỗ trợ của FSS và TEF là Dịch vụ Mempool (MS). MS có thể được xem như một bộ chuyển đổi, nhưng một với sự hỗ trợ hạng nhất. MS cung cấp hỗ trợ cho việc xử lý giao dịch tương thích với kế thừa. Trong việc sử dụng này, MS nhập vào từ bộ nhớ của chuỗi chính những giao dịch dành cho hợp đồng mục tiêu SC trên MAINCHAIN. Sau đó MS chuyển các giao dịch này tới một tệp thực thi trên DON, nơi chúng được xử lý theo cách mong muốn. Dữ liệu MS có thể được sử dụng bởi DON để soạn các giao dịch mà sau đó có thể được chuyển trực tiếp tới SC từ DON hoặc tới một hợp đồng khác gọi SC. Ví dụ: DON có thể chuyển tiếp giao dịch được thu thập thông qua MS hoặc nó có thể sử dụng dữ liệu MS để đặt giá gas cho các giao dịch mà nó gửi tới CHUỖI MAIN. Vì nó giám sát mempool nên MS có thể thu được các giao dịch từ người dùng tương tác trực tiếp với SC. Do đó, người dùng có thể tiếp tục tạo giao dịch của mình bằng cách sử dụng phần mềm cũ, tức là các ứng dụng không biết đến sự tồn tại của MS và được cấu hình MS hợp đồng. (Trong trường hợp này, SC phải được thay đổi để bỏ qua các giao dịch ban đầu và chỉ chấp nhận những dữ liệu được MS xử lý để tránh xử lý kép.) Để sử dụng với hợp đồng mục tiêu SC, MS có thể được sử dụng với FSS và/hoặc TEF.3.6 Bước đệm: Khả năng Chainlink hiện có 3.6.1 Báo cáo ngoài chuỗi (OCR) Báo cáo chuỗi Off (OCR) [60] là một cơ chế trong Chainlink để tổng hợp và truyền báo cáo oracle tới SC hợp đồng dựa trên. Được triển khai gần đây với giá Chainlink mạng nguồn cấp dữ liệu, nó thể hiện bước đầu tiên trên đường dẫn đến DON đầy đủ. Về cốt lõi, OCR là giao thức BFT được thiết kế để hoạt động ở chế độ đồng bộ một phần mạng. Nó đảm bảo tính sống động và đúng đắn khi có mặt f < n/3 một cách tùy ý các nút bị lỗi, đảm bảo các đặc tính của chương trình phát sóng đáng tin cậy của Byzantine, nhưng không phải vậy một giao thức đồng thuận BFT hoàn chỉnh. Các nút không duy trì nhật ký tin nhắn nhất quán theo nghĩa đại diện cho một sổ cái giống hệt nhau về mọi quan điểm của họ, và người đứng đầu giao thức có thể lập lờ mà không vi phạm an toàn. OCR hiện được thiết kế cho một loại thông báo cụ thể: tổng hợp trung bình của (ít nhất 2f +1) giá trị được báo cáo bởi các nút tham gia. Nó cung cấp một sự đảm bảo quan trọng về các báo cáo mà nó xuất ra cho SC, được gọi là các báo cáo được chứng thực: Giá trị trung bình trong một báo cáo được chứng thực báo cáo bằng hoặc nằm giữa các giá trị được báo cáo bởi hai nút trung thực. Tài sản này là điều kiện an toàn chính cho OCR. Người lãnh đạo có thể có một số ảnh hưởng ở mức trung bình giá trị trong một báo cáo được chứng thực, nhưng chỉ tuân theo điều kiện về tính chính xác này. OCR có thể được mở rộng cho các loại thông báo tổng hợp các giá trị theo nhiều cách khác nhau. Mặc dù mục tiêu về tính chính xác và hoạt động của mạng Chainlink ngày nay không yêu cầu OCR là một giao thức đồng thuận toàn diện, chúng yêu cầu OCR cung cấp một số dạng chức năng bổ sung không có trong các giao thức BFT thông thường, đáng chú ý nhất là: 1. Phát báo cáo ngoài chuỗi tất cả hoặc không có gì: OCR đảm bảo rằng báo cáo được chứng thực được cung cấp nhanh chóng cho tất cả các nút trung thực hoặc không nút nào trong số chúng. Đây là một sự công bằng thuộc tính giúp đảm bảo rằng các nút trung thực có cơ hội tham gia trong việc truyền báo cáo được chứng thực. 2. Đường truyền đáng tin cậy: OCR đảm bảo, ngay cả khi có lỗi hoặc độc hại các nút, rằng tất cả các báo cáo và tin nhắn OCR được truyền đến SC trong một khoảng thời gian nhất định, khoảng thời gian được xác định trước. Đây là một tài sản sống động. 3. Giảm thiểu độ tin cậy dựa trên hợp đồng: SC lọc ra các báo cáo do OCR tạo có khả năng sai sót, ví dụ: nếu giá trị được báo cáo của chúng sai lệch đáng kể so với các báo cáo khác những cái đã nhận được gần đây. Đây là một hình thức thực thi tính đúng đắn của giao thức bổ sung. Cả ba thuộc tính này sẽ đóng vai trò tự nhiên trong DONs. Chương trình phát sóng tất cả hoặc không có gì trên chuỗi (DON) là một khối xây dựng quan trọng để đảm bảo kinh tế tiền điện tử xung quanh việc truyền tải đáng tin cậy, do đó đây là một thuộc tính thiết yếu của bộ điều hợp. Tin tưởng giảm thiểu trong SC là một loại đường ray bảo vệ, như được thảo luận trong Phần 7.3. OCR cũng cung cấp cơ sở cho việc triển khai hoạt động và cải tiến các giao thức BFT trong mạng oracle của Chainlink và do đó, như đã lưu ý ở trên, một đường dẫn đến toàn bộ chức năng của DONs.3.6.2 DECO và Town Crier DECO [234] và Town Crier [233] là một cặp công nghệ liên quan hiện đang được sử dụng được phát triển trong mạng Chainlink. Hầu hết các máy chủ web ngày nay đều cho phép người dùng kết nối qua kênh bảo mật bằng giao thức được gọi là Bảo mật lớp vận chuyển (TLS) [94]. (HTTPS biểu thị một biến thể của HTTP được bật bằng TLS, tức là các URL có tiền tố “https” biểu thị việc sử dụng TLS để bảo mật.) Tuy nhiên, hầu hết các máy chủ hỗ trợ TLS đều có một hạn chế đáng chú ý: Chúng không ký điện tử dữ liệu. Do đó, người dùng hoặc Prover không thể hiển thị dữ liệu cô ấy nhận được từ máy chủ cho bên thứ ba hoặc Người xác minh, chẳng hạn như oracle hoặc smart contract, theo cách đảm bảo tính xác thực của dữ liệu. Ngay cả khi máy chủ ký dữ liệu bằng chữ ký điện tử thì vẫn có vấn đề về tính bảo mật. Nhà cung cấp có thể muốn biên tập lại hoặc sửa đổi dữ liệu nhạy cảm trước khi trình bày nó với Người xác minh. Tuy nhiên, chữ ký số được thiết kế đặc biệt để vô hiệu hóa dữ liệu đã sửa đổi. Do đó, chúng ngăn cản Prover thực hiện các thay đổi bảo đảm tính bảo mật tới dữ liệu. (Xem Phần 7.1 để thảo luận thêm.) DECO và Town Crier được thiết kế để cho phép Prover lấy dữ liệu từ trang web máy chủ và trình nó cho Người xác minh theo cách đảm bảo tính toàn vẹn và bảo mật. Hai hệ thống duy trì tính toàn vẹn theo nghĩa là chúng đảm bảo rằng dữ liệu được trình bày bởi Prover cho Verifier có nguồn gốc xác thực từ máy chủ mục tiêu. Họ hỗ trợ tính bảo mật theo nghĩa cho phép Prover biên tập lại hoặc sửa đổi dữ liệu (trong khi vẫn bảo toàn tính toàn vẹn). Đặc điểm chính của cả hai hệ thống là chúng không yêu cầu bất kỳ sửa đổi nào đối với máy chủ web mục tiêu. Họ có thể hoạt động với bất kỳ máy chủ hỗ trợ TLS hiện có nào. Trên thực tế, chúng minh bạch đối với máy chủ: Từ quan điểm của máy chủ, Prover là thiết lập một kết nối thông thường. Hai hệ thống này có các mục tiêu tương tự nhau, nhưng khác nhau về mô hình tin cậy và cách triển khai như chúng tôi sẽ giải thích ngắn gọn. DECO sử dụng cơ bản các giao thức mã hóa để đạt được tính toàn vẹn của nó và các thuộc tính bảo mật. Trong khi thiết lập phiên với máy chủ mục tiêu bằng DECO, Prover đồng thời tham gia vào một giao thức tương tác với Người xác minh. Giao thức này cho phép Người chứng minh chứng minh với Người xác minh rằng nó đã nhận được một phần dữ liệu D nhất định từ máy chủ trong phiên hiện tại của nó. Người Prover có thể hoặc đưa ra cho Người xác minh bằng chứng không có kiến thức về một số thuộc tính của D và do đó không tiết lộ trực tiếp D. Trong cách sử dụng DECO thông thường, người dùng hoặc một nút có thể xuất dữ liệu D từ một máy chủ riêng tư. phiên với máy chủ web tới tất cả các nút trong DON. Kết quả là toàn bộ DON có thể chứng thực tính xác thực của D (hoặc một sự thật bắt nguồn từ D thông qua bằng chứng không có kiến thức). Ngoài các ứng dụng ví dụ được đưa ra sau trong bài viết, khả năng này có thể được được sử dụng để khuếch đại quyền truy cập có tính toàn vẹn cao vào nguồn dữ liệu bằng DON. Ngay cả khi chỉ có một nút có quyền truy cập trực tiếp vào nguồn dữ liệu—ví dụ: do một thỏa thuận độc quyền với nhà cung cấp dữ liệu—toàn bộ DON vẫn có thể chứng thực tính đúng đắn củacác báo cáo được phát ra bởi nút đó. Town Crier dựa vào việc sử dụng môi trường thực thi đáng tin cậy (TEE) như Intel SGX. Tóm lại, TEE hoạt động như một loại hộp đen thực thi các ứng dụng trong một môi trường cách chống giả mạo và bí mật. Về nguyên tắc, ngay cả chủ sở hữu máy chủ lưu trữ trên đó TEE đang chạy không thể (không thể phát hiện) làm thay đổi ứng dụng được bảo vệ bởi TEE cũng như không xem trạng thái của ứng dụng, có thể bao gồm dữ liệu bí mật. Town Crier có thể đạt được tất cả chức năng của DECO và hơn thế nữa. DECO hạn chế Nhà cung cấp tương tác với một Người xác minh duy nhất. Ngược lại, Town Crier cho phép Nhà cung cấp tạo ra bằng chứng có thể xác minh công khai về dữ liệu D được tìm nạp từ máy chủ mục tiêu, tức là bằng chứng cho thấy bất kỳ ai, kể cả smart contract, đều có thể xác minh trực tiếp. Town Crier có thể cũng nhập và sử dụng các bí mật một cách an toàn (ví dụ: thông tin xác thực của người dùng). Hạn chế chính của Town Crier là sự phụ thuộc vào TEE. TEE sản xuất có gần đây đã được chứng minh là có một số lỗ hổng nghiêm trọng, mặc dù công nghệ này vẫn còn ở giai đoạn sơ khai và chắc chắn sẽ trưởng thành. Xem Phụ lục B.2.1 và B.2.2 để biết thảo luận thêm về TEE. Để biết một số ứng dụng mẫu của DECO và Town Crier, hãy xem Phần 4.3, 4.5 và 9.4.3 và Phụ lục C.1. 3.6.3 Dịch vụ trên chuỗi hiện có Chainlink Chainlink oracle mạng cung cấp một số dịch vụ chính trên nhiều mạng blockchains và các hệ thống phi tập trung khác hiện nay. Sự tiến hóa hơn nữa như mô tả trong sách trắng này sẽ cung cấp cho các dịch vụ hiện có này những khả năng và đạt được. Ba ví dụ là: Nguồn cấp dữ liệu: Ngày nay, phần lớn Chainlink người dùng dựa vào smart contracts thực hiện việc sử dụng nguồn cấp dữ liệu. Đây là những báo cáo về giá trị hiện tại của các phần dữ liệu quan trọng theo đến các nguồn có thẩm quyền ngoài chuỗi. Ví dụ: nguồn cấp dữ liệu giá là nguồn cấp dữ liệu báo cáo giá về tài sản—tiền điện tử, hàng hóa, ngoại hối, chỉ số, cổ phiếu, v.v.—theo dịch vụ trao đổi hoặc tổng hợp dữ liệu. Những nguồn cấp dữ liệu như vậy ngày nay đã giúp đảm bảo hàng tỷ giá trị đô la trên chuỗi thông qua việc sử dụng chúng trong các hệ thống DeFi như Aave [147] và Tổng hợp [208]. Các ví dụ khác về nguồn cấp dữ liệu Chainlink bao gồm dữ liệu thời tiết cho bảo hiểm cây trồng tham số [75] và dữ liệu bầu cử [93], cùng một số dữ liệu khác. Việc triển khai DON và các công nghệ khác được mô tả trong bài viết này sẽ tăng cường việc cung cấp nguồn cấp dữ liệu trong mạng Chainlink theo nhiều cách, bao gồm: • Mở rộng quy mô: OCR và sau đó là DON nhằm mục đích cho phép các dịch vụ Chainlink mở rộng quy mô đáng kể trên nhiều blockchain mà họ hỗ trợ. Ví dụ, chúng tôi mong đợi DON sẽ giúp tăng số lượng nguồn cấp dữ liệu do các nút cung cấp bằng cách sử dụng Chainlink từ 100 đến 1000 và hơn thế nữa. Việc chia tỷ lệ như vậy sẽ giúp Chainlink hệ sinh thái đạt được mục tiêu cung cấp dữ liệu liên quan đến smart contract một cách toàn diện, đồng thời vừa đáp ứng vừa dự đoán các nhu cầu hiện tại và tương lai.• Bảo mật nâng cao: Bằng cách lưu trữ các báo cáo trung gian, DONs sẽ giữ lại các bản ghi về hành vi của nút để theo dõi và đo lường độ chính xác cao về hiệu suất và độ chính xác của chúng, tạo nền tảng thực nghiệm vững chắc cho các hệ thống danh tiếng cho các nút Chainlink. FSS và TEF sẽ cho phép kết hợp nguồn cấp dữ liệu giá với dữ liệu giao dịch theo những cách linh hoạt để ngăn chặn các cuộc tấn công như chạy trước. (Rõ ràng) staking sẽ tăng cường bảo vệ an ninh kinh tế tiền điện tử hiện có của nguồn cấp dữ liệu. • Tính linh hoạt của nguồn cấp dữ liệu: Vì blockchain hệ thống bất khả tri (thực ra, rộng hơn là hệ thống bất khả tri về người tiêu dùng), DONs có thể tạo điều kiện thuận lợi cho việc cung cấp nguồn cấp dữ liệu cho nhiều nơi của các hệ thống dựa vào. Một DON có thể đẩy đồng thời một nguồn cấp dữ liệu nhất định vào một tập hợp của blockchain khác nhau, loại bỏ nhu cầu về mạng oracle trên mỗi chuỗi và cho phép triển khai nhanh chóng các nguồn cấp dữ liệu hiện có trên blockchain mới và các nguồn cấp dữ liệu bổ sung nguồn cấp dữ liệu trên blockchain hiện được phục vụ. • Tính bảo mật: Khả năng thực hiện tính toán tổng quát trong DON cho phép tính toán trên dữ liệu nhạy cảm diễn ra ngoài chuỗi, tránh xảy ra trên chuỗi tiếp xúc. Ngoài ra, bằng cách sử dụng DECO hoặc Town Crier, có thể đạt được tính bảo mật thậm chí còn mạnh mẽ hơn, cho phép tạo báo cáo dựa trên dữ liệu không chính xác tiếp xúc ngay cả với các nút DON. Xem Phần 4.3 và Phần 4.5 để biết ví dụ. Hàm ngẫu nhiên có thể xác minh (VRF): Một số loại DApp yêu cầu nguồn ngẫu nhiên chính xác có thể xác minh được để cho phép xác minh hoạt động công bằng của chính chúng. Mã thông báo không thể thay thế (NFTs) là một ví dụ. Độ hiếm của các tính năng NFT trong Aavegotchi [23] và Axie Infinity [35] được xác định bởi Chainlink VRF, cũng như sự phân bố trong số NFT bằng cách rút thăm dựa trên vé trong Thẻ Ether [102]; sự đa dạng của DApp chơi game có kết quả ngẫu nhiên; và các công cụ tài chính độc đáo, ví dụ: trò chơi tiết kiệm không thua lỗ như PoolTogether [89], phân bổ vốn cho người chiến thắng ngẫu nhiên. Các ứng dụng blockchain và không phảiblockchain khác cũng yêu cầu bảo mật nguồn ngẫu nhiên, bao gồm việc lựa chọn các ủy ban hệ thống phi tập trung và thực hiện xổ số. Mặc dù các khối hash có thể đóng vai trò là nguồn ngẫu nhiên không thể đoán trước nhưng chúng dễ bị thao túng bởi những người khai thác đối nghịch (và ở một mức độ nào đó bởi người dùng gửi giao dịch). Chainlink VRF [78] cung cấp giải pháp thay thế an toàn hơn đáng kể. Một oracle có cặp khóa riêng/chung được liên kết (sk, pk) có khóa riêng được duy trì ngoài chuỗi và khóa chung pk được công bố. Để xuất ra một giá trị ngẫu nhiên, nó áp dụng sk cho hạt giống x không thể đoán trước được cung cấp bởi một hợp đồng dựa trên (ví dụ: khối hash và các tham số dành riêng cho DApp) bằng cách sử dụng hàm F, mang lại y = Fsk(x) cùng với a bằng chứng về tính đúng đắn. (Xem [180] để biết VRF có sẵn trên Chainlink.) Điều gì tạo nên một VRF có thể kiểm chứng được là thực tế là với kiến thức về pk, có thể kiểm tra tính đúng đắn của chứng minh và do đó của y. Do đó, giá trị y không thể đoán trước được đối với một đối thủ không thể dự đoán x hoặc tìm hiểu sk và dịch vụ không thể thao túng.Chainlink VRF có thể được xem chỉ là một trong nhóm ứng dụng liên quan đến việc giám sát các khóa riêng tư trên chuỗi. Tổng quát hơn, DON có thể cung cấp tính bảo mật, lưu trữ phi tập trung các khóa riêng lẻ cho ứng dụng và/hoặc người dùng và kết hợp khả năng này với tính toán tổng quát. Kết quả là một loạt các ứng dụng, mà chúng tôi đưa ra một số ví dụ trong bài viết này, bao gồm quản lý khóa cho Bằng chứng về Dự trữ (xem Phần 4.1) và thông tin xác thực phi tập trung của người dùng (và các thông tin kỹ thuật số khác tài sản) (xem Phần 4.3). Người giữ: Chainlink Keepers [87] cho phép các nhà phát triển viết mã cho phi tập trung thực thi các công việc ngoài chuỗi, thường là để kích hoạt thực thi các smart contract dựa vào. Trước khi Keepers ra đời, các nhà phát triển thường vận hành những ứng dụng ngoài chuỗi như vậy logic, tạo ra các điểm thất bại tập trung (cũng như nỗ lực phát triển trùng lặp đáng kể). Thay vào đó, Keepers cung cấp một khuôn khổ dễ sử dụng cho gia công phần mềm phi tập trung cho các hoạt động này, cho phép chu kỳ phát triển ngắn hơn và đảm bảo mạnh mẽ về tính sống động và các đặc tính bảo mật khác. Người giữ có thể hỗ trợ bất kỳ của nhiều mục tiêu kích hoạt khác nhau, bao gồm việc thanh lý các khoản vay hoặc thực hiện các giao dịch tài chính, bắt đầu các đợt airdrop hoặc thanh toán phụ thuộc vào thời gian trong các hệ thống thu hoạch năng suất, v.v. Trong khuôn khổ DON, người khởi xướng có thể được xem là sự khái quát hóa của Người quản lý theo một số nghĩa. Người khởi xướng có thể sử dụng các bộ điều hợp và do đó có thể tận dụng thư viện giao diện được mô-đun hóa cho các hệ thống trên chuỗi và ngoài chuỗi, cho phép nhanh chóng phát triển các chức năng an toàn, phức tạp. Người khởi xướng bắt đầu tính toán trong các tệp thực thi, bản thân chúng cung cấp tính linh hoạt đầy đủ của DON, cho phép phạm vi rộng một loạt các dịch vụ phi tập trung mà chúng tôi trình bày trong bài viết này dành cho các ứng dụng trên chuỗi và ngoài chuỗi. 3.6.4 Danh tiếng nút / Lịch sử hiệu suất Hệ sinh thái Chainlink hiện tại ghi lại lịch sử hiệu suất của các nút đóng góp trên chuỗi. Tính năng này đã tạo ra một tập hợp các tài nguyên định hướng danh tiếng để thu thập, lọc và trực quan hóa dữ liệu hiệu suất trên từng cá nhân. nhà khai thác nút và nguồn cấp dữ liệu. Người dùng có thể tham khảo các tài nguyên này để cung cấp thông tin quyết định trong việc lựa chọn các nút và giám sát hoạt động của các mạng hiện có. Khả năng tương tự sẽ giúp người dùng chọn DONs. Ví dụ: các thị trường không được phép ngày nay như market.link cho phép nút nhà khai thác liệt kê các dịch vụ oracle của họ và chứng thực danh tính ngoài chuỗi của họ thông qua các dịch vụ như Keybase [4], liên kết hồ sơ của một nút trong Chainlink với nó tên miền và tài khoản truyền thông xã hội hiện có của chủ sở hữu. Ngoài ra, hiệu suất các công cụ phân tích, chẳng hạn như các công cụ có sẵn tại market.link và uy tín.link, cho phép người dùng xem số liệu thống kê về hiệu suất lịch sử của các nút riêng lẻ, bao gồm cả nút của họ độ trễ phản hồi trung bình, độ lệch của các giá trị trong báo cáo của họ so với giá trị đồng thuận được chuyển tiếp trên chuỗi, doanh thu được tạo ra, công việc được hoàn thành, v.v. Những công cụ phân tích này cũng cho phép người dùng theo dõi việc sử dụng các mạng oracle khác nhau của những người dùng khác, một dạngsự chứng thực ngầm định của các nút bảo vệ các mạng như vậy. Kết quả là một “mạng lưới” phẳng tin cậy”, trong đó, bằng cách sử dụng các nút cụ thể, các ứng dụng phi tập trung có giá trị cao sẽ tạo ra một tín hiệu về sự tin tưởng của họ đối với các nút đó mà người dùng khác có thể quan sát và tính đến quyết định lựa chọn nút riêng. Với DONs (và ban đầu là OCR) dẫn đến sự thay đổi trong xử lý giao dịch và hoạt động hợp đồng nói chung hơn là ngoài chuỗi. Một mô hình phi tập trung cho nút ghi vẫn có thể thực hiện được hiệu suất trong chính DON. Quả thực, hiệu suất cao và dung lượng dữ liệu DONs giúp có thể xây dựng các bản ghi ở dạng chi tiết cách và cũng để thực hiện tính toán phi tập trung trên các hồ sơ này, mang lại những bản tóm tắt đáng tin cậy có thể được sử dụng bởi các dịch vụ danh tiếng và được kiểm tra trên CHUỖI MAIN. Mặc dù về nguyên tắc DON có thể trình bày sai hành vi của các nút cấu thành nếu một phần lớn các nút bị hỏng, chúng tôi lưu ý rằng tập thể hiệu suất của chính DON trong việc phân phối dữ liệu trên chuỗi được hiển thị trên MAINCHAIN và do đó không thể bị trình bày sai. Ngoài ra, chúng tôi dự định khám phá các cơ chế khuyến khích báo cáo nội bộ chính xác về hành vi của nút trong DON. Ví dụ: bằng cách báo cáo tập hợp con các nút có hiệu suất cao trả về dữ liệu đóng góp nhanh nhất đối với một báo cáo được chuyển tiếp trên chuỗi, DON tạo động lực cho các nút tranh chấp không chính xác báo cáo: Việc bao gồm các nút trong tập hợp con này không chính xác có nghĩa là loại trừ các nút không chính xác điều đó lẽ ra phải được đưa vào và do đó trừng phạt họ một cách vô hiệu. Việc DON báo cáo lỗi lặp đi lặp lại cũng sẽ tạo ra động cơ khuyến khích các nút trung thực rời khỏi DON. Biên soạn phi tập trung lịch sử hiệu suất chính xác và hậu quả khả năng của người dùng trong việc xác định các nút có hiệu suất cao và để người vận hành nút xây dựng danh tiếng là đặc điểm phân biệt quan trọng của hệ sinh thái Chainlink. Chúng tôi trình bày trong Phần 9 cách chúng ta có thể suy luận về chúng như một phần quan trọng của một hệ thống chặt chẽ và cái nhìn mở rộng về an ninh kinh tế được cung cấp bởi DONs.

分散型 Oracle ネットワーク インターフェイスと Ca-

能力 ここでは、シンプルかつ強力な観点から DONs の機能を簡単に説明します。 インターフェイスを実現するように設計されています。 DON 上のアプリケーションは、実行可能ファイルとアダプターで構成されます。実行可能ファイルは、 smart contract に類似した、コア ロジックが決定論的プログラムであるプログラム。 実行可能ファイルには、エントリを呼び出すプログラムであるイニシエーターも多数付属しています。 事前に決定されたイベントが発生したとき (特定の時間など)、実行可能ファイルのロジック内のポイント (cron ジョブのように)、価格がしきい値を超えたときなど、Keepers (セクション 3.6.3 を参照) とよく似ています。アダプターはオフチェーン リソースへのインターフェイスを提供し、アダプターによって呼び出されます。 イニシエーターまたは実行可能ファイルのコア ロジックのいずれか。彼らの行動はそれに依存する可能性があるため、 外部リソース、イニシエーター、アダプターは非決定的に動作する可能性があります。 DON 開発者インターフェイスと実行可能ファイルの機能について説明します。 コンピューティング システムを特徴付けるために通常使用される 3 つのリソース (ネットワーキング、コンピューティング、ストレージ) の観点からアダプターを説明します。これらのそれぞれについて簡単に概要を説明します 以下のリソースを参照し、付録 B で詳細を説明します。

Adapters connecting a DON with different resources including blockchains, web servers, storage, and IoT devices

3.1 ネットワーキング アダプターは、DON 上で実行される実行可能ファイルが送信および送信できるインターフェイスです。 DON のシステムからデータを受信します。アダプターは、以下を一般化したものと見なすことができます。 Chainlink で現在 [20] で使用されているアダプター。アダプターは双方向である場合があります。 DON から Web サーバーにデータをプルするだけでなく、プッシュすることもできます。彼らはまた、活用するかもしれません 分散プロトコルと安全なマルチパーティなどの暗号化機能 計算。 図 9: DON1 で示される DON を、DON2 で示される別の DON、blockchain (メイン チェーン) およびそのリソースを含むさまざまなリソースに接続するアダプター mempool、外部ストレージ、Web サーバー、IoT デバイス (Web サーバー経由)。 アダプターが作成される可能性のある外部リソースの例が示されています。 図 9 には次のものが含まれます。 • ブロックチェーン: アダプターはトランザクションを blockchain に送信する方法を定義でき、 そこからブロック、個々のトランザクション、またはその他の状態を読み取る方法。アダプター blockchain のメモリプールに対して定義することもできます。 (セクション 3.5 を参照してください。) • Web サーバー: アダプターは、データを取得するための API を定義できます。 Web サーバー (特別に適応されていないレガシー システムを含む) から DON とのインターフェース。このようなアダプターには、データを送信するための API を含めることもできます。 そのようなサーバー。 DON が接続する Web サーバーはゲートウェイとして機能する可能性があります モノのインターネット (IoT) デバイスなどの追加リソースにアクセスします。• 外部ストレージ: アダプタはストレージの読み取りおよび書き込みメソッドを定義できます。 分散型ファイル システム [40、188] やクラウドなど、DON の外部のサービス 保管。 • その他の DON: アダプターは、DON 間でデータを取得および送信できます。 DONs の初期展開には一連の構成要素が含まれることを期待しています このような一般的に使用される外部リソース用のアダプターが追加され、DON 固有の DON ノードによって公開されるアダプター。 smart contract 開発者がアダプターを作成するとき 今日、私たちは彼らがこの高度な機能を使用してさらに強力なアダプターを構築することを期待しています。 機能性。 最終的にはユーザーが新しいアダプターを作成できるようになると期待しています。 許可のないやり方。 一部のアダプターは、DON によって制御される外部リソースの永続性と可用性を保証する方法で構築する必要があります。たとえば、クラウド ストレージでは、 クラウド サービス アカウントのメンテナンスが必要です。さらに、DON は次のことを実行できます。 ユーザーに代わって秘密鍵を分散管理する ([160] など) および/または 実行可能ファイル。その結果、DON は、ターゲット blockchain でトランザクションを送信するなどに使用できる、暗号通貨などのリソースを制御できます。 DON アダプターの詳細については付録 B.1 を参照してください。一部のアダプターについては付録 C を参照してください。 アダプターの例。 3.2 計算 実行可能ファイルは、DON 上のコードの基本単位です。実行可能ファイルは exec = のペアです。 (ロジック、初期化)。ここで、ロジックは指定されたエントリを多数持つ決定的なプログラムです。 ポイント (logic1、logic2、...、logicℓ) および init は対応するイニシエーターのセットです (init1、init2、...、inite)。 DON の完全な監査可能性を確保するには、実行可能ファイルのロジック すべての入力と出力に対して基礎となる元帳 L を使用します。したがって、たとえば、どのアダプターでも 実行可能ファイルへの入力として機能するデータは、最初に L に保存する必要があります。 イニシエーター: 現在、Chainlink のイニシエーターにより、イベントに依存したジョブが実行されます。 Chainlink ノード [21]。 DONs のイニシエーターは、ほぼ同じように機能します。ただし、DON イニシエーターは、具体的には実行可能ファイルに関連付けられます。イニシエーターは依存する可能性があります 外部のイベントまたは状態、現在の時刻、または DON 状態の述語に基づいて。 イベントに依存しているため、イニシエーターは当然ながら非決定的に動作する可能性があります。 (もちろんアダプターも同様です)。イニシエーターは個々の DON ノード内で実行できます したがって、アダプターに依存する必要はありません。 (以下の例 1 を参照してください。) イニシエーターは、実行可能ファイルと smart contract を区別する重要な機能です。 実行可能ファイルはイニシエーターに応答して実行できるため、効率的に動作できます。 もちろん、拡張により、実行可能ファイルを組み込んだハイブリッド コントラクトを自律的に実行できます。現在のイニシエーターの 1 つの形式は、トランザクションを提供する Chainlink キーパーです。oracle レポートに基づいて、smart contract 実行 (担保不足ローンの清算や指値注文取引の実行など) をトリガーする自動化サービス。 便利なことに、DONs のイニシエーターは、 実行可能ファイルに適用されるサービス契約。サービス契約は以下の状況を定義します。 DON はこれを呼び出す必要があります。 次の例は、実行可能ファイル内でイニシエーターがどのように動作するかを示しています。 例 1 (偏差によってトリガーされる価格フィード)。 smart contract SC には新しいものが必要な場合があります 価格フィードデータ (セクション 3.6.3 を参照) に大幅な変化 (例: 1%) があるときは常に 資産ペア間の為替レート（ETH-USD など）。ボラティリティに敏感な価格 フィードは現在 Chainlink でサポートされていますが、どのようにサポートできるかを確認することは有益です。 実行可能ファイル execfeed によって DON 上で実現されます。 実行可能ファイル execfeed は、L 上の最新の ETH-USD 価格 r を維持します。 ⟨NewPrice : j, r⟩entries のシーケンスの形式。j はインデックスで増分されます。 各価格の更新。 イニシエーター init1 により、各ノード Oi は現在の ETH-USD 価格を監視します。 インデックス j で最後に保存された価格 r から少なくとも 1% の偏差。次第 このような偏差を検出すると、Oi は新しい価格の現在のビュー ri を次のように L に書き込みます。 ⟨PriceView : i, j + 1, ri⟩ という形式のエントリ。 2 番目のイニシエーター init2 は、新しい価格を持つそのような PriceView エントリーが少なくとも k 個あるときに起動します。 個別のノードによって作成されたインデックス j + 1 の値が L に蓄積されます。その後、init2 エントリ ポイントのロジック 2 を呼び出して、最初の k 個の新鮮な有効なpriceview 値の中央値 ρ を計算し、新しい値 ⟨NewPrice : j + 1, ρ⟩ を L に書き込みます。 (運用上、ノードは 交代で指定作家となる場合があります。） 3 番目のイニシエーター init3 は、L 上の NewPrice エントリーを監視します。新しいレポートが作成されるたびに、 そこに ⟨NewPrice : j, r⟩ が表示され、(j, r) を SC にプッシュするエントリ ポイント ロジック 3 が呼び出されます。 アダプターを使用して。 すでに述べたように、実行可能ファイルの機能は smart contract と似ています。 ただし、パフォーマンスが高いことは別として、典型的なメインチェーン契約とは異なります。 2 つの重要な方法で: 1. 機密性: 実行可能ファイルは機密の計算を実行できます。つまり、秘密のプログラムが平文入力を処理したり、公開されたプログラムが処理したりできます。 秘密の入力データ、または両方の組み合わせ。単純なモデルでは、機密データは次のようになります。 DON ノードからアクセスできます。中間結果は隠蔽され、のみが公開されます。 処理およびサニタイズされた値を MAINCHAIN に送信します。 DON 自体から機密データを隠すことも可能です。 DON は、次のようなアプローチをサポートすることを目的としています。 マルチパーティ計算 ([42, 157] など)、および信頼できる実行環境として (TEE) [84, 133, 152, 229] この目的のために。6 6拡張により、DON ノードに関して実行可能ファイル自体を秘密にしておくことも可能です。 ただし、これは現在、TEE を使用する重要な実行可能ファイルに対してのみ実用的です。2. サポートの役割: 実行可能ファイルは、メインの smart contracts をサポートすることを目的としています。 交換するのではなく、チェーンに交換してください。実行可能ファイルにはいくつかの制限があります。 smart contract は次のことを行いません: (a) 信頼モデル: 実行可能ファイルは、 DON: 正しく実行されるかどうかは、O の誠実な行動に依存します。(メイン ただし、チェーンは DON 不正行為に対するガード レールを提供できます。 セクション 7.3 で説明します)。 (b) 資産アクセス: DON は blockchain のアカウントを制御できるため、 アダプターを介してその上の資産を制御します。しかし、DON は権限を与えることができません メインチェーン上で作成された資産 (例: Ether または ERC20 tokens) を表します。 彼らのネイティブチェーンは、彼らの所有権の信頼できる記録を維持します。 (c) ライフサイクル: DON は、次のように、限られたライフタイムで意図的に起動される場合があります。 DON と所有者との間のオンチェーン サービス レベル アグリーメントによって定義される 依存契約の。 対照的に、ブロックチェーンは次のように機能することを目的としています。 永久アーカイブシステム。 DON 計算の詳細については、付録 B.2 を参照してください。 3.3 ストレージ 委員会ベースのシステムとして、DON は適度な量のデータを永続的に保存できます L では、権限のない blockchain よりもはるかに低コストで利用できます。さらに、アダプターを介して、 DONs は、ファイルコイン [85] など、データ ストレージ用の外部分散システムを参照できます。 これにより、そのようなシステムを smart contract に接続できるようになります。このオプションは特に 蔓延する「肥大化」の問題に対処する手段として、大量のデータにとって魅力的です。 blockchain システム。 したがって、DON は、特定のサポートされているサービスで使用するためにデータをローカルまたは外部に保存できます。 DON はさらに、そのようなデータを機密性の高い方法で利用できます。 次のようなデータを計算します: (1) DON ノード間で秘密が共有されているか、または暗号化されている 安全なマルチパーティ計算に適した方法で DON ノードによって管理されるキー または部分的または完全な準同型暗号化。または (2) 信頼できる実行を使用して保護される 環境。 DONs は、 スマート コントラクト システム: 実行可能ファイルは、それ自体のメモリにのみ書き込むことができます。実行可能ファイル ただし、他の実行可能ファイルのメモリから読み取ることはできます。 DON ストレージの詳細については、付録 B.3 を参照してください。 3.4 トランザクション実行フレームワーク (TEF) DON は、メイン チェーン MAINCHAIN (または複数のメイン チェーン) でコントラクトをサポートすることを目的としています。トランザクション実行フレームワーク (TEF) について詳しく説明しますセクション 6 では、契約を効率的に実行するための汎用アプローチです。 MAINCHAIN および DON にわたる SC。 TEF は、FSS とレイヤー 2 をサポートすることを目的としています。 必要に応じて、テクノロジーを同時に利用できます。まさに主力車両として活躍しそうです FSS の使用のためです (そのため、このセクションでは FSS についてはこれ以上説明しません)。 簡単に言うと、TEF では、MAINCHAIN 用に設計または開発されたオリジナルのターゲット コントラクト SC ハイブリッド コントラクトにリファクタリングされます。このリファクタリングにより、2 つの相互運用性が生成されます。 ハイブリッド コントラクトの一部: 明確にするために参照する MAINCHAIN コントラクト SCa TEF のコンテキストではアンカー コントラクトとして、実行可能ファイルは DON 上で実行されます。の 契約SCaはユーザーの資産を保管し、権限のある状態遷移を実行し、また DON の障害に対するガード レール (セクション 7.3 を参照) を提供します。実行可能ファイル exec トランザクションをシーケンスし、それらに関連する oracle データを提供します。同梱可能です 有効性証明ベースの使用や、 楽観的なrollup、DONによる機密実行など。 開発者が契約を簡単に分割できるツールの開発を期待しています。 高級言語で MAINCHAIN および DON ロジックの部分に書かれた SC、SCa および それぞれ実行され、安全かつ効率的に構成されます。 TEF を使用して高パフォーマンスのトランザクション スキームと高パフォーマンスのトランザクション スキームを統合する oracles は、oracle スケーリング アプローチに不可欠です。 3.5 メンプールサービス サポート対象の DONs にデプロイする予定の重要なアプリケーション層機能 FSS および TEF は Mempool Services (MS) です。 MS はアダプターと見なすこともできますが、 ただし、一流のサポートが付いています。 MS は、レガシー互換のトランザクション処理のサポートを提供します。この用途では、MS ターゲットコントラクトを対象としたトランザクションをメインチェーンのメモリプールから取り込みます メインチェーン上の SC。その後、MS はこれらのトランザクションを DON 上の実行可能ファイルに渡します。 目的の方法で処理されます。 MS データは DON で使用できます DON から SC に直接渡すことができるトランザクションを作成する、または SC を呼び出す別のコントラクトに接続します。たとえば、DON はトランザクションを転送できます。 MS 経由で収集することも、MS データを使用して送信先のトランザクションのガス価格を設定することもできます メインチェーン。 MS はメモリプールを監視するため、SC と直接対話するユーザーからトランザクションを取得できます。したがって、ユーザーは引き続き次を使用してトランザクションを生成できます。 レガシー ソフトウェア、つまり MS および MS で構成されたアプリケーションの存在を認識しないアプリケーション 契約。 (この場合、元のトランザクションを無視するように SC を変更する必要があります。 二重処理を避けるために、MS によって処理されたもののみを受け入れます。) ターゲット契約 SC で使用する場合、MS は FSS および/または TEF で使用できます。3.6 ステッピング ストーン: 既存の Chainlink 機能 3.6.1 オフチェーンレポート (OCR) オフチェーン レポート (OCR) [60] は、oracle レポートの集約と依存コントラクト SC への送信のための Chainlink のメカニズムです。最近Chainlink価格で導入されました フィード ネットワークでは、完全な DON へのパスに沿った最初のステップを表します。 OCR の核心は、部分同期で動作するように設計された BFT プロトコルです。 ネットワーク。 f < n/3 の存在下での生存性と正確性を任意に保証します 障害のあるノードは、ビザンチンの信頼できるブロードキャストの特性を保証しますが、そうではありません。 完全な BFT コンセンサス プロトコル。ノードは次のようなメッセージ ログを維持しません。 すべてのビューで同一の台帳を表すという意味での一貫性。 そして、プロトコルのリーダーは、安全性を侵害することなく曖昧な発言をする可能性があります。 OCR は現在、特定のメッセージ タイプ、つまり中央値化されたメッセージ タイプ向けに設計されています。 (少なくとも 2f +1) の値が参加ノードによって報告されます。重要な保証を提供します。 SC に対して出力するレポートは、証明済みレポートと呼ばれます。 証明済みレポートの中央値 レポートは、2 つの正直なノードによってレポートされた値と等しいか、その間にあります。この物件は OCR の重要な安全条件。リーダーは中央値に何らかの影響を与える可能性がある ただし、この正当性条件のみが条件となります。 OCRできる さまざまな方法で値を集計するメッセージ タイプに拡張できます。 Chainlink ネットワークの稼働性と正確性の今日の目標では、 OCR が本格的なコンセンサス プロトコルであるためには、従来の BFT プロトコルには存在しないいくつかの追加形式の機能を提供するために OCR が必要です。特に注目すべきは次のとおりです。 1.オール・オア・ナッシングのオフチェーン・レポート・ブロードキャスト: OCRにより、証明されたレポートが確実に送信されます。 すべての正直なノードがすぐに利用できるようになるか、どのノードも利用できないようになります。これは公平性です 正直なノードが参加する機会を確実に得るのに役立つプロパティ 証明されたレポート送信において。 2. 信頼性の高い送信: OCR により、欠陥や悪意のあるデータが存在する場合でも確実に送信されます。 すべての OCR レポートとメッセージが特定のノード内で SC に送信されること、 事前定義された時間間隔。これは活性プロパティです。 3. 契約ベースの信頼の最小化: SC は、たとえば、報告された値が他の値と大きく異なる場合など、誤った可能性がある OCR 生成レポートを除外します。 最近受け取ったもの。これは、プロトコル外の正確性の強制の一種です。 これら 3 つのプロパティはすべて、DON で自然な役割を果たします。オール オアナッシング オフチェーン (DON) ブロードキャストは、暗号経済保証の重要な構成要素です 信頼性の高い伝送が重要であり、これがアダプターの重要な特性となります。信頼 セクション 7.3 で説明したように、SC の最小化は一種のガード レールです。 OCR は、Chainlink の oracle ネットワークにおける BFT プロトコルの運用展開と改良のための基盤も提供するため、前述したように、完全なネットワークへの道が提供されます。 DON の機能。3.6.2 DECOとタウンクライヤー DECO [234] と Town Crier [233] は、現在開発されている 2 つの関連テクノロジーです。 Chainlink ネットワークで開発されました。 現在、ほとんどの Web サーバーでは、ユーザーはプロトコルを使用して安全なチャネル経由で接続できます。 Transport Layer Security (TLS) [94] と呼ばれます。 (HTTPS は、HTTP のバリアントを示します。 TLS が有効になっています。つまり、「https」という接頭辞が付いている URL は、セキュリティのために TLS を使用していることを示します。) ただし、ほとんどの TLS 対応サーバーには、デジタル署名が行われないという顕著な制限があります。 データ。したがって、ユーザーまたは証明者はサーバーから受け取ったデータを提示できません。 oracle や smart contract などの第三者または検証者に、 データの信頼性。 たとえサーバーがデータにデジタル署名したとしても、機密性の問題が残ります。証明者は、機密データを提出する前に編集または変更したい場合があります。 検証者。ただし、デジタル署名は、変更されたデータを無効にするために特別に設計されています。したがって、証明者が機密保持のための変更を行うのを防ぎます。 データに。 (詳細については、セクション 7.1 を参照してください。) DECO と Town Crier は、証明者が Web からデータを取得できるように設計されています。 サーバーに保存し、完全性と機密性が保証される方法で検証者に提示します。 2 つのシステムは、提供されるデータが確実に保持されるという意味で整合性を維持します。 証明者から検証者への送信は、ターゲット サーバーから確実に発信されます。彼らはサポートします 証明者がデータを編集または変更できるようにするという意味での機密性（まだ 完全性の維持）。 両方のシステムの主な特徴は、システムを変更する必要がないことです。 ターゲットWebサーバー。これらは、既存の TLS 対応サーバーであればどれでも動作できます。実際、 それらはサーバーに対して透過的です。サーバーの観点から見ると、証明者は次のようになります。 通常の接続を確立します。 2 つのシステムは同様の目標を持っていますが、ここで簡単に説明するように、信頼モデルと実装が異なります。 DECO は、暗号化プロトコルを基本的に利用して完全性を実現します そして機密性のプロパティ。 DECO を使用してターゲット サーバーとのセッションを確立している間、証明者は同時に、ターゲット サーバーとの対話型プロトコルを実行します。 検証者。このプロトコルにより、証明者は、自分が受け取ったものを検証者に証明することができます。 現在のセッション中にサーバーからの特定のデータ D 。証明者は次のことを行うことができます 代わりに、D の何らかのプロパティのゼロ知識証明を検証者に提示します。 したがって、D を直接明らかにすることはありません。 DECO の一般的な使用法では、ユーザーまたは単一ノードがプライベート データベースからデータ D をエクスポートできます。 DON 内のすべてのノードに対する Web サーバーとのセッション。その結果、完全な DON は、 D (またはゼロ知識証明によって D から導出された事実) の信頼性を証明します。 この文書で後ほど説明するサンプル アプリケーションに加えて、この機能は次のようにすることができます。 DON によるデータ ソースへの高整合性アクセスを増幅するために使用されます。ノードが 1 つだけであっても たとえば、との排他的取り決めにより、データ ソースに直接アクセスできます。 データプロバイダー - DON 全体がデータの正確さを証明することが可能です。そのノードによって発行されたレポート。 Town Crier は、Intel などの信頼できる実行環境 (TEE) の使用に依存しています。 SGX。簡単に言うと、TEE はアプリケーションを実行する一種のブラック ボックスとして機能します。 改ざん防止と機密性の高い方法。原則として、ホストの所有者であっても、 実行中の TEE は、TEE で保護されたアプリケーションを (検出されずに) 変更することも、 アプリケーションの状態を表示します。これには機密データが含まれる場合があります。 タウンクライエはDECOの機能をすべて実現し、それ以上の機能を実現できます。 DECO は、証明者を単一の検証者と対話するように制限します。対照的に、Town Crier では、 ターゲットサーバーから取得したデータDに対して公的に検証可能な証明を生成する証明者、 つまり、smart contract であっても、誰でも直接検証できるという証拠です。タウンクライヤー缶 また、シークレット (ユーザー認証情報など) を安全に取り込んで利用します。 Town Crier の主な制限は、TEE への依存です。プロダクション TEE には、 このテクノロジーはまだ初期段階にあり、間違いなく成熟するでしょうが、最近、多くの深刻な脆弱性があることが判明しました。詳細については、付録 B.2.1 および B.2.2 を参照してください。 TEE についてさらに詳しく説明します。 DECO と Town Crier のいくつかのアプリケーション例については、セクション 4.3、4.5 を参照してください。 9.4.3 および付録 C.1。 3.6.3 既存のオンチェーン Chainlink サービス Chainlink oracle ネットワークは、多数の主要なサービスを提供します。 blockchains やその他の今日の分散システム。 説明どおりのさらなる進化 このホワイトペーパーでは、これらの既存のサービスに追加の機能を与え、 届く。 3 つの例は次のとおりです。 データフィード: 現在、smart contract に依存している Chainlink ユーザーの大多数は、 データフィードの使用。これらは、主要なデータ部分の現在の値に関するレポートです。 信頼できるオフチェーンの情報源に送信します。たとえば、価格フィードは価格を報告するフィードです。 によると、仮想通貨、コモディティ、外国為替、インデックス、株式などの資産の 交換またはデータ集約サービス。このようなフィードは今日すでに数十億ドルの安全を確保するのに役立っています Aave [147] や シンセティクス [208]。 Chainlink データ フィードの他の例には、次のような気象データが含まれます。 パラメトリック作物保険 [75] や選挙データ [93] など。 このペーパーで説明されている DON およびその他のテクノロジーの展開により、Chainlink ネットワークでのデータ フィードの提供が次のようなさまざまな方法で強化されます。 • スケーリング: OCR とその後の DON は、Chainlink サービスのスケーリングを可能にすることを目的としています。 サポートする多くの blockchain にわたって劇的に効果的です。たとえば、私たちが期待しているのは、 DONs は、ノードによって提供されるデータ フィードの数を増やすのに役立ちます。 Chainlink 100 年代から 1000 年代、そしてそれ以上まで。このようなスケーリングは、Chainlink に役立ちます。 エコシステムは、smart contract に関連するデータを包括的に提供し、既存および将来のニーズを満たし、予測するという目標を達成します。• セキュリティの強化: 中間レポートを保存することで、DONs は記録を保持します。 ノードの動作を正確に監視し、そのパフォーマンスと精度を測定することで、レピュテーション システムの強力な経験的根拠を実現します。 Chainlink ノードの場合。 FSS と TEF により、価格フィードの組み込みが可能になります フロントランニングなどの攻撃を防ぐ柔軟な方法でトランザクション データを使用します。 (明示的) staking は、既存の暗号経済的なセキュリティ保護を強化します。 データフィードの。 • フィードの俊敏性: blockchain に依存しないシステム (実際、より広義には消費者に依存しないシステム) として、DON は複数の組織へのデータ フィードのプロビジョニングを容易にします。 依存するシステムの。単一の DON は、指定されたフィードを同時にセットにプッシュできます さまざまな blockchain を使用できるため、チェーンごとの oracle ネットワークが不要になり、 新しい blockchain および追加のフィードの既存のフィードの迅速なデプロイメントを可能にします。 現在サービスされている blockchain にわたるフィード。 • 機密性: DON で一般化された計算を実行できる機能により、機密データの計算をオフチェーンで実行できるようになり、オンチェーンを回避できます。 露出。 また、DECOやタウンクライエを利用することで、 機密性がさらに強化され、非公開データに基づいたレポート生成が可能になります。 DON ノードにも公開されます。例については、セクション 4.3 およびセクション 4.5 を参照してください。 検証可能なランダム関数 (VRF): いくつかの種類の DApp は、自身の公正な動作を検証できるように、検証可能な正しいランダム性ソースを必要とします。 代替不可能なトークン (NFTs) がその例です。 Aavegotchi [23] および Axie Innity [35] の NFT フィーチャーの希少性は、分布と同様に Chainlink VRF によって決まります。 Ether カード [102] のチケットベースの描画による NFT 件。多種多様な 結果がランダム化されるゲーム DApps。および非伝統的な金融商品、たとえば、PoolTogether [89] などの損失のない貯蓄ゲームなど、 ランダムな勝者。他のblockchainおよびblockchain以外のアプリケーションも安全なセキュリティを必要とします 分散システム委員会の選択や、 宝くじの実施。 ブロック hashes は予測不可能なランダム性のソースとして機能する可能性がありますが、敵対的なマイナーによる操作に対して脆弱です (また、ある程度はユーザーの送信による操作に対しても脆弱です) トランザクション）。 Chainlink VRF [78] は、より安全な代替手段を提供します。アン oracle には、秘密鍵と公開鍵のペア (sk、pk) が関連付けられており、その秘密鍵はオフチェーンで維持され、公開鍵 pk は公開されます。ランダムな値を出力するには、 依存コントラクト (ブロック hash など) によって提供される予測不可能なシード x に sk を適用します。 および DApp 固有のパラメーター）関数 F を使用して、y = Fsk(x) と、 正しさの証明。 (Chainlink で利用可能な VRF については、[180] を参照してください。) VRF が検証可能であるということは、pk の知識があれば、証明の正しさ、したがって y の正しさをチェックできるという事実です。したがって、値 y は、ユーザーにとって予測不可能です。 x を予測したり、sk を学習したりすることができず、サービスが操作することは不可能な敵対者。Chainlink VRF は、オフチェーンの秘密キーの管理を伴うアプリケーション ファミリの 1 つにすぎないとみなされる場合があります。より一般的には、DON は安全なセキュリティを提供します。 アプリケーションおよび/またはユーザーの個別のキーの分散ストレージ、およびそれらの組み合わせ この機能は一般化された計算で実現されます。その結果、多数のアプリケーションが作成されます。 このホワイトペーパーでは、Proof of of のためのキー管理を含むいくつかの例を示します。 リザーブ (セクション 4.1 を参照) およびユーザーの分散型認証情報 (およびその他のデジタル情報) 資産) (セクション 4.3 を参照)。 キーパー: Chainlink Keepers [87] により、開発者は分散型のコードを作成できます オフチェーン ジョブの実行。通常は依存する smart contract の実行をトリガーします。 Keepers が登場する前は、開発者がこのようなオフチェーンを運用するのが一般的でした。 ロジックそのものが原因で、集中的な障害点が発生します (また、かなりの重複した開発作業も発生します)。キーパーは代わりに、使いやすいフレームワークを提供します。 これらの業務の分散型アウトソーシングにより、開発サイクルの短縮と 生存性およびその他のセキュリティ特性の強力な保証。キーパーは何でもサポートできます 価格に応じたローンの清算や、 金融取引の実行、時間に応じたエアドロップまたは支払いの開始 収量収穫を伴うシステムなど。 DON フレームワークでは、イニシエーターは、さまざまな意味でキーパーを一般化したものと見なすことができます。イニシエータはアダプタを利用することができるため、 オンチェーンおよびオフチェーン システムへのインターフェイスのモジュール化されたライブラリにより、迅速な 安全で洗練された機能の開発。イニシエーターは計算を開始します 実行可能ファイル自体が DON の完全な多用途性を提供し、幅広い機能を可能にします。 このホワイトペーパーでは、オンチェーンおよびオフチェーンのアプリケーション向けにさまざまな分散サービスを紹介します。 3.6.4 ノードの評判/パフォーマンス履歴 既存の Chainlink エコシステムは、パフォーマンス履歴をネイティブに文書化します。 チェーン上のノードに貢献します。この機能により、個人のパフォーマンス データを取り込み、フィルタリングし、視覚化する評判指向のリソースのコレクションが誕生しました。 ノードオペレーターとデータフィード。ユーザーはこれらのリソースを参照して情報を得ることができます ノードの選択における決定と、既存のネットワークの運用の監視を行います。 同様の機能は、ユーザーが DON を選択するのに役立ちます。 たとえば、今日のmarket.linkなどのパーミッションレスマーケットプレイスでは、ノードが許可されています。 オペレータは、oracle サービスをリストし、オフチェーン ID を証明します。 Keybase [4] などのサービス。Chainlink のノードのプロファイルをそのノードにバインドします。 所有者の既存のドメイン名とソーシャルメディアアカウント。さらに、パフォーマンス マーケット.リンクやレピュテーション.リンクで入手可能な分析ツールなどを使用すると、 ユーザーは、個々のノードの履歴パフォーマンスに関する統計を表示できます。 平均応答待ち時間、コンセンサス値からのレポートの値の偏差 チェーンで中継され、生み出された収益、達成された仕事など。これらの分析ツールも ユーザーが他のユーザーによるさまざまな oracle ネットワークの採用を追跡できるようにします。このようなネットワークを保護するノードの暗黙の承認。その結果、平坦な「ウェブ」が形成されます。 「信頼」。特定のノードを使用することで、高価値の分散アプリケーションが 他のユーザーがそれを観察して考慮に入れることができる、それらのノードに対する信頼のシグナル。 独自のノード選択決定。 DONs (および最初は OCR) により、トランザクション処理が変化し、 契約アクティビティは、より一般的にはオフチェーンです。レコーディングノードの分散モデル DON 自体の内部でもパフォーマンスは引き続き可能です。まさに、高性能 DONs のデータ容量により、きめ細かいレコードの構築が可能になります。 これらのレコードに対して分散計算を実行し、レピュテーション サービスで使用したりチェックポイントを作成したりできる信頼できる概要を生成します。 メインチェーン。 原理的には、大部分のノードが破損している場合、DON が構成ノードの動作を誤って表現する可能性がありますが、集合的な オンチェーン データの配信における DON 自体のパフォーマンスは MAINCHAIN で確認できます したがって、誤って伝えることはできません。さらに、 DON でノードの動作に関する正確な内部レポートを奨励します。たとえば、貢献するデータを最も早く返す高性能ノードのサブセットを報告することによって、 チェーン上で中継されるレポートに対して、DON はノードが不正な内容に異議を唱えるインセンティブを生み出します。 レポート: このサブセットにノードが誤って含まれているということは、ノードが誤って除外されていることを意味します これは含まれるべきであったため、無効に罰せられるべきでした。 DON によるレポートの失敗が繰り返されると、誠実なノードがそのシステムから離脱するインセンティブも生成されます。 DON。 正確なパフォーマンス履歴とその結果の分散型編集 ユーザーが高性能ノードを特定し、ノードオペレーターが構築できる能力 評判は、Chainlink エコシステムの重要な特徴です。 私たち セクション 9 で、これらを厳密な分析の重要な部分としてどのように推論できるかを示します。 DONs によって提供される経済的安全性の広範なビュー。

Dịch vụ phi tập trung được kích hoạt bởi phi tập trung

Mạng Oracle Để minh họa tính linh hoạt của DON và cách chúng kích hoạt một loạt dịch vụ mới, chúng tôi trình bày năm ví dụ về các ứng dụng dựa trên DON trong phần này và mô tả hợp đồng kết hợp hiện thực hóa chúng: (1) Bằng chứng dự trữ, một hình thức dịch vụ chuỗi chéo; (2) Giao tiếp với các hệ thống doanh nghiệp/cũ, tức là tạo ra một ứng dụng dựa trên phần mềm trung gian lớp trừu tượng tạo điều kiện phát triển các ứng dụng blockchain với chi phí tối thiểu blockchain-mã hoặc chuyên môn cụ thể; (3) Nhận dạng phi tập trung, các công cụ cho phép người dùng có được và quản lý các tài liệu nhận dạng và thông tin xác thực của riêng họ; (4) Các kênh ưu tiên, một dịch vụ đảm bảo đưa vào kịp thời các giao dịch cơ sở hạ tầng quan trọng (ví dụ: oracle báo cáo) trên blockchain; và (5) Bảo đảm bí mật DeFi, nghĩa là tài chính smart contract che giấu dữ liệu nhạy cảm của các bên tham gia. Ở đây, chúng tôi

sử dụng SC để biểu thị phần MAINCHAIN của hợp đồng kết hợp và mô tả DON thành phần riêng biệt hoặc dưới dạng một chương trình thực thi có thể thực thi được. 4.1 Bằng chứng dự trữ Đối với nhiều ứng dụng, việc chuyển tiếp trạng thái giữa hoặc giữa blockchains là rất hữu ích. A ứng dụng phổ biến của các dịch vụ như vậy là gói tiền điện tử. Những đồng xu được bọc như vậy vì WBTC [15] đang trở thành tài sản phổ biến trong Tài chính phi tập trung (DeFi). Họ liên quan đến việc gửi tài sản hỗ trợ “được bao bọc” vào nguồn của nó blockchain MAINCHAIN(1) và tạo token tương ứng trên một mục tiêu khác, blockchain MAINCHAIN(2). Ví dụ: WBTC là ERC20 token trên Ethereum blockchain tương ứng tới BTC trên Bitcoin blockchain. Vì các hợp đồng trên MAINCHAIN(2) không hiển thị trực tiếp vào MAINCHAIN(1), họ phải dựa một cách rõ ràng hoặc ngầm định vào oracle để báo cáo về khoản tiền gửi của gói được bao bọc nội dung trong smart contract, tạo ra cái mà đôi khi được gọi là Bằng chứng dự trữ. trong Ví dụ: WBTC [15], người giám sát BitGo nắm giữ BTC và phát hành WBTC, với Chainlink mạng cung cấp Bằng chứng dự trữ [76]. DON có thể tự cung cấp Bằng chứng dự trữ. Tuy nhiên, với DON, có thể để đi xa hơn DON có thể quản lý bí mật và thông qua việc sử dụng bộ điều hợp thích hợp, có thể giao dịch trên bất kỳ blockchain nào mong muốn. Do đó, DON có thể hành động với tư cách là một trong số những người giám hộ—hoặc thậm chí là người giám hộ duy nhất, phi tập trung—cho một tài sản được bọc. DON do đó có thể đóng vai trò là nền tảng để nâng cao tính bảo mật của các dịch vụ hiện có sử dụng Bằng chứng dự trữ. Ví dụ: giả sử MAINCHAIN(1) là Bitcoin và MAINCHAIN(2) là Ethereum. Trên MAINCHAIN(2), SC hợp đồng phát hành tokens đại diện cho BTC được bao bọc. DON kiểm soát địa chỉ BTC (1) DON. Sau đó, để bọc BTC, người dùng U gửi X BTC từ địa chỉ (1) bạn để thêm (1) DON cùng với địa chỉ MAINCHAIN(2)-địa chỉ (2) bạn. Màn hình DON địa chỉ (1) DON thông qua bộ chuyển đổi sang MAINCHAIN(1). Khi quan sát tiền gửi của U, với xác nhận có xác suất đủ cao, nó sẽ gửi một tin nhắn đến SC thông qua bộ chuyển đổi tới CHUỖI CHÍNH(2). Thông báo này hướng dẫn SC đúc X tokens cho addr(2) bạn. Để U giải phóng X tokens thì điều ngược lại sẽ xảy ra. Tuy nhiên, trên MAINCHAIN(1), địa chỉ (1) DON gửi X BTC tới addr(1) U (hoặc đến địa chỉ khác, nếu người dùng yêu cầu). Tất nhiên, các giao thức này có thể được điều chỉnh để hoạt động với các sàn giao dịch, thay vì trực tiếp. với người dùng. 4.2 Giao diện với hệ thống doanh nghiệp / kế thừa DON có thể đóng vai trò là cầu nối giữa và giữa blockchain, như trong ví dụ về Bằng chứng của Dự trữ, nhưng một mục tiêu khác là để chúng đóng vai trò là cầu nối hai chiều giữa blockchains và các hệ thống kế thừa [176] hoặc các hệ thống tương tự blockchain chẳng hạn như ngân hàng trung ương tiền kỹ thuật số [30]. Các doanh nghiệp phải đối mặt với một số thách thức trong việc kết nối các hệ thống hiện có của họ và quy trình cho các hệ thống phi tập trung, bao gồm:• Tính linh hoạt của chuỗi khối: Hệ thống chuỗi khối thay đổi nhanh chóng. Doanh nghiệp có thể phải đối mặt với sự xuất hiện mới nhanh chóng hoặc mức độ phổ biến ngày càng tăng của blockchains các đối tác mong muốn thực hiện giao dịch nhưng doanh nghiệp không có hỗ trợ cơ sở hạ tầng hiện có của nó. Nhìn chung, sự năng động của blockchains tạo nên rất khó để các doanh nghiệp riêng lẻ có thể theo kịp hệ sinh thái đầy đủ. • Nguồn lực phát triển dành riêng cho chuỗi khối: Đối với nhiều tổ chức, việc tuyển dụng hoặc ươm tạo chuyên môn blockchain tiên tiến là rất khó khăn, đặc biệt là khi xét đến thử thách sự nhanh nhẹn. • Quản lý khóa riêng: Quản lý khóa riêng cho blockchain hoặc tiền điện tử yêu cầu chuyên môn vận hành khác với chuyên môn về an ninh mạng truyền thống thực tiễn và không có sẵn cho nhiều doanh nghiệp. • Tính bảo mật: Các doanh nghiệp rất thận trọng khi tiết lộ thông tin nhạy cảm và độc quyền của mình dữ liệu trên chuỗi. Để giải quyết ba khó khăn đầu tiên, nhà phát triển chỉ cần sử dụng DON như một lớp phần mềm trung gian an toàn để cho phép các hệ thống doanh nghiệp đọc từ hoặc ghi vào blockchains. DON có thể tóm tắt những cân nhắc kỹ thuật chi tiết như động lực khí, tổ chức lại chuỗi, v.v. cho cả nhà phát triển và người dùng. Bởi trình bày giao diện blockchain được sắp xếp hợp lý cho các hệ thống doanh nghiệp, do đó DON có thể đơn giản hóa đáng kể việc phát triển các ứng dụng doanh nghiệp nhận biết blockchain, loại bỏ gánh nặng cho các doanh nghiệp trong việc mua hoặc ươm tạo các tài nguyên phát triển cụ thể blockchain. Việc sử dụng DON như vậy đặc biệt hấp dẫn ở chỗ nó cho phép các nhà phát triển doanh nghiệp tạo các ứng dụng hợp đồng thông minh phần lớn là blockchain bất khả tri. Kết quả là, lớn hơn tập hợp blockchain trong đó DON được thiết kế để hoạt động như phần mềm trung gian, lớn hơn tập hợp blockchain mà người dùng doanh nghiệp có thể dễ dàng truy cập. Nhà phát triển có thể chuyển các ứng dụng từ blockchain hiện có sang ứng dụng mới với sự sửa đổi tối thiểu cho các ứng dụng được phát triển nội bộ của họ. Để giải quyết vấn đề bổ sung về tính bảo mật, các nhà phát triển có thể khiếu nại lên cơ quan các công cụ chúng tôi giới thiệu trong bài viết này và dự kiến sẽ triển khai để hỗ trợ các ứng dụng DON. Chúng bao gồm DECO và Town Crier Mục 3.6.2 cũng như bảo vệ bí mật Các sửa đổi API được thảo luận trong Phần 7.1.2 và một số cách tiếp cận dành riêng cho ứng dụng được đề cập trong phần còn lại của phần này. Những hệ thống DON này có thể cung cấp chứng thực trực tuyến, có tính toàn vẹn cao về trạng thái hệ thống doanh nghiệp mà không tiết lộ dữ liệu nguồn doanh nghiệp nhạy cảm trên chuỗi. 4.3 Nhận dạng phi tập trung Danh tính phi tập trung là một thuật ngữ chung cho khái niệm mà người dùng có thể lấy và quản lý thông tin xác thực của riêng họ, thay vì dựa vào bên thứ ba để thực hiện vậy. Thông tin xác thực phi tập trung là sự chứng thực cho các thuộc tính hoặc xác nhận của chủ sở hữu,thường được gọi là yêu cầu bồi thường. Thông tin xác thực được ký điện tử bởi các thực thể, thường được gọi là nhà phát hành, có thể liên kết chính xác các khiếu nại với người dùng. Trong hầu hết các phương án được đề xuất, các khiếu nại được liên kết với Mã định danh phi tập trung (DID), một mã định danh chung cho một người dùng nhất định. Thông tin xác thực được liên kết với khóa chung mà người dùng nắm giữ khóa riêng. Do đó, người dùng có thể chứng minh quyền sở hữu yêu cầu bằng cách sử dụng khóa riêng của mình. Có tầm nhìn xa trông rộng như bản sắc phi tập trung, các kế hoạch hiện có và được đề xuất, ví dụ: [14, 92, 129, 216], có ba hạn chế nghiêm trọng: • Thiếu khả năng tương thích kế thừa: Các hệ thống nhận dạng phi tập trung hiện tại dựa vào một cộng đồng các cơ quan có thẩm quyền, được gọi là tổ chức phát hành, để tạo ra thông tin xác thực DID. Bởi vì các dịch vụ web hiện tại thường không ký điện tử dữ liệu, các tổ chức phát hành phải được triển khai như các hệ thống có mục đích đặc biệt. Bởi vì không có động cơ để làm điều này mà không có hệ sinh thái nhận dạng phi tập trung sẽ dẫn đến vấn đề con gà và quả trứng. Ở nơi khác Nói cách khác, vẫn chưa rõ cách khởi động hệ sinh thái của nhà phát hành. • Quản lý khóa không thể thực hiện được: Hệ thống nhận dạng phi tập trung yêu cầu người dùng quản lý khóa riêng, điều mà trải nghiệm với tiền điện tử đã cho thấy là một trách nhiệm không thể thực hiện được. Người ta ước tính có khoảng 4.000.000 Bitcoin đã được bị mất vĩnh viễn do lỗi quản lý khóa [194] và nhiều người dùng lưu trữ tài sản tiền điện tử với các sàn giao dịch [193], do đó làm suy yếu tính phân cấp. • Thiếu khả năng chống lại Sybil bảo vệ quyền riêng tư: Yêu cầu bảo mật cơ bản của các ứng dụng như bỏ phiếu, phân bổ công bằng tokens trong khi bán token, v.v. là người dùng không thể xác nhận nhiều danh tính. Các đề xuất nhận dạng phi tập trung hiện tại yêu cầu người dùng tiết lộ danh tính trong thế giới thực của họ để đạt được điều đó. Khả năng chống lại âm thanh, do đó làm suy yếu các đảm bảo quyền riêng tư quan trọng. Có thể giải quyết những vấn đề này bằng cách sử dụng sự kết hợp của một ủy ban các nút thực hiện tính toán phân tán trong DON và sử dụng các công cụ như DECO hoặc Town Crier, như được hiển thị trong hệ thống có tên CanDID [160]. DECO hoặc Town Crier có thể thiết kế để biến đổi các dịch vụ web hiện có mà không cần sửa đổi vào các nhà phát hành thông tin xác thực bảo mật. Chúng cho phép DON xuất có liên quan dữ liệu cho mục đích này thành thông tin xác thực đồng thời che giấu dữ liệu nhạy cảm không được phép xuất hiện trong thông tin xác thực. Ngoài ra, để tạo thuận lợi cho việc khôi phục khóa cho người dùng, từ đó giải quyết vấn đề quản lý khóa. vấn đề, DON có thể cho phép người dùng lưu trữ khóa riêng tư ở dạng chia sẻ bí mật. Người dùng có thể khôi phục khóa của họ bằng cách chứng minh cho các nút trong DON—tương tự, sử dụng Town Crier hoặc DECO—khả năng đăng nhập vào tài khoản với một nhóm nhà cung cấp web được xác định trước (ví dụ: Twitter, Google, Facebook). Lợi ích của việc sử dụng Town Crier hoặc DECO, trái ngược với OAUTH, là quyền riêng tư của người dùng. Hai công cụ đó cho phép người dùng tránh tiết lộ cho DON một mã định danh nhà cung cấp web—từ đó thường có thể lấy được danh tính trong thế giới thực. Cuối cùng, để cung cấp khả năng kháng Sybil, như được hiển thị trong [160], DON có thể thực hiện chuyển đổi bảo vệ quyền riêng tư của các mã nhận dạng duy nhất trong thế giới thực cho người dùng (ví dụ: Số An sinh Xã hội (SSN)) thành số nhận dạng trên chuỗi khi đăng ký người dùng.Do đó, hệ thống có thể phát hiện các đăng ký trùng lặp mà không có dữ liệu nhạy cảm như SSN được tiết lộ cho các nút DON riêng lẻ.7 DON có thể cung cấp bất kỳ dịch vụ nào trong số này thay mặt cho danh tính phi tập trung bên ngoài các hệ thống trên blockchains không được phép hoặc được phép, ví dụ: các phiên bản của Hyperledger Ấn Độ [129]. Ứng dụng ví dụ: KYC: Bản sắc phi tập trung hứa hẹn sẽ là một phương tiện để hợp lý hóa các yêu cầu đối với các ứng dụng tài chính trên blockchains đồng thời cải thiện khả năng sử dụng của người dùng sự riêng tư. Hai thách thức mà nó có thể giúp giải quyết là các nghĩa vụ công nhận và tuân thủ theo các quy định chống rửa tiền/biết khách hàng (AML/KYC). Các quy định về AML ở nhiều quốc gia yêu cầu các tổ chức tài chính (và các doanh nghiệp khác) thiết lập và xác minh danh tính của các cá nhân và doanh nghiệp liên quan. họ thực hiện các giao dịch. KYC là một thành phần của tổ chức tài chính chính sách AML rộng hơn, thường liên quan đến việc giám sát hành vi của người dùng và theo dõi dòng vốn, cùng nhiều hoạt động khác. KYC thường yêu cầu người dùng trình bày thông tin xác thực danh tính dưới một số hình thức (ví dụ: nhập vào một biểu mẫu web trực tuyến, giơ tài liệu nhận dạng trước mặt người dùng trong một phiên video, v.v.). Tạo và trình bày an toàn thông tin xác thực phi tập trung về nguyên tắc có thể là một giải pháp thay thế có lợi ở một số khía cạnh, cụ thể là bằng cách: (1) Tạo quy trình KYC hiệu quả hơn đối với người dùng và tổ chức tài chính, bởi vì một khi có được thông tin xác thực, nó có thể được trình bày liền mạch cho bất kỳ tổ chức tài chính nào; (2) Giảm gian lận bằng cách giảm cơ hội đánh cắp danh tính thông qua thỏa hiệp thông tin nhận dạng cá nhân (PII) và giả mạo trong quá trình xác minh video; và (3) Giảm nguy cơ xâm phạm PII trong các tổ chức tài chính, khi người dùng giữ quyền kiểm soát dữ liệu của chính họ. Với các khoản phạt trị giá hàng tỷ đô la mà các tổ chức tài chính phải trả vì không tuân thủ AML và nhiều tổ chức tài chính chi hàng triệu đô la hàng năm cho KYC, các cải tiến có thể mang lại khoản tiết kiệm đáng kể cho các tổ chức tài chính. và nói rộng ra là dành cho người tiêu dùng [196]. Trong khi khu vực tài chính truyền thống chậm để áp dụng các công cụ tuân thủ mới, các hệ thống DeFi đang ngày càng áp dụng công cụ này [43]. Ứng dụng ví dụ: Các khoản vay không được thế chấp: Hầu hết DeFi ứng dụng hỗ trợ cho vay ngày nay chỉ bắt nguồn từ các khoản vay có thế chấp đầy đủ. Đây là những khoản vay được thực hiện cho những người đi vay gửi tài sản tiền điện tử có giá trị vượt quá giá trị của khoản vay. Gần đây đã nảy sinh sự quan tâm đến điều mà cộng đồng DeFi thường gọi là các khoản vay không được thế chấp. Ngược lại, đây là những khoản vay có tài sản thế chấp tương ứng có giá trị nhỏ hơn giá trị gốc của khoản vay. Các khoản vay không có tài sản thế chấp giống với các khoản vay thường được thực hiện bởi các tổ chức tài chính truyền thống. Thay vì dựa vào trên tài sản thế chấp ký gửi như một sự đảm bảo trả nợ, thay vào đó họ căn cứ vào việc cho vay quyết định về lịch sử tín dụng của người vay. 7Việc chuyển đổi này dựa trên hàm giả ngẫu nhiên phân tán (PRF).Các khoản vay không được thế chấp là một phần non trẻ nhưng đang phát triển của thị trường cho vay DeFi. Họ dựa vào các cơ chế giống như các cơ chế được sử dụng bởi các tổ chức tài chính truyền thống các tổ chức, chẳng hạn như hợp đồng pháp lý [91]. Một yêu cầu thiết yếu cho sự phát triển của họ sẽ là khả năng cung cấp dữ liệu về mức độ tín nhiệm của người dùng—yếu tố chính trong các quyết định cho vay thông thường—đến các hệ thống DeFi theo cách cung cấp tính toàn vẹn mạnh mẽ, tức là, đảm bảo số liệu chính xác. Hệ thống nhận dạng phi tập trung được kích hoạt DON sẽ cho phép những người đi vay tương lai tạo ra các thông tin có độ đảm bảo cao chứng thực mức độ tin cậy của họ trong khi vẫn bảo toàn tính bảo mật của thông tin nhạy cảm. Cụ thể, người đi vay có thể tạo ra những thông tin xác thực dựa trên hồ sơ từ các nguồn trực tuyến có thẩm quyền trong khi chỉ hiển thị thông tin dữ liệu được chứng thực bởi DON mà không làm lộ dữ liệu có thể nhạy cảm khác. cho Ví dụ: người đi vay có thể tạo thông tin xác thực cho biết rằng điểm tín dụng của cô ấy có nhóm văn phòng tín dụng vượt quá một ngưỡng cụ thể (ví dụ: 750) mà không tiết lộ thông tin của cô ấy điểm chính xác hoặc bất kỳ dữ liệu nào khác trong hồ sơ của cô ấy. Ngoài ra, nếu muốn, thông tin xác thực đó có thể được tạo ẩn danh, tức là tên người dùng có thể được coi là dữ liệu nhạy cảm và bản thân nó không được tiếp xúc với các nút oracle hoặc trong thông tin xác thực phi tập trung của cô ấy. Thông tin xác thực bản thân nó có thể được sử dụng trên chuỗi hoặc ngoài chuỗi, tùy thuộc vào ứng dụng. Tóm lại, người đi vay có thể cung cấp thông tin cần thiết cho người cho vay về tín dụng của họ. lịch sử có tính toàn vẹn cao và không có nguy cơ phơi bày những thông tin nhạy cảm, không cần thiết dữ liệu. Người vay cũng có thể cung cấp nhiều loại thông tin xác thực bảo mật khác hữu ích trong việc đưa ra quyết định cho vay. Ví dụ: thông tin xác thực có thể chứng thực quyền sở hữu của người đi vay sở hữu tài sản (ngoài chuỗi), như chúng tôi trình bày trong ví dụ tiếp theo. Ứng dụng ví dụ: Chứng nhận: Nhiều khu vực pháp lý giới hạn loại nhà đầu tư có thể bán chứng khoán chưa đăng ký. Ví dụ: ở Mỹ, SEC Quy định D quy định rằng để được công nhận cho những cơ hội đầu tư như vậy, cá nhân phải sở hữu tài sản ròng trị giá 1 triệu USD, đáp ứng các yêu cầu về thu nhập tối thiểu nhất định hoặc có trình độ chuyên môn nhất định [209, 210]. Sự công nhận hiện tại các quy trình rườm rà và kém hiệu quả, thường đòi hỏi phải có thư xác nhận từ kế toán viên hoặc bằng chứng tương tự. Một hệ thống nhận dạng phi tập trung sẽ cho phép người dùng tạo thông tin xác thực từ các tài khoản dịch vụ tài chính trực tuyến hiện có chứng minh sự tuân thủ chứng nhận các quy định, tạo điều kiện cho quy trình KYC hiệu quả hơn và bảo vệ quyền riêng tư hơn. các Hơn nữa, các đặc tính bảo vệ quyền riêng tư của DECO và Town Crier sẽ cho phép những điều này thông tin xác thực được tạo với sự đảm bảo mạnh mẽ về tính toàn vẹn mà không tiết lộ trực tiếp chi tiết về tình trạng tài chính của người dùng. Ví dụ: người dùng có thể tạo thông tin xác thực chứng minh rằng cô ấy có tài sản ròng ít nhất là 1 triệu đô la mà không tiết lộ thêm bất kỳ điều gì thông tin về tình trạng tài chính của cô ấy. 4.4 Kênh ưu tiên Kênh ưu tiên là một dịch vụ mới hữu ích, dễ xây dựng bằng DON. của họ

Diagram of basic Mixicle showing on-chain secrecy with private oracle reporting

Priority channel diagram showing a miner guarantee for transaction ordering to protect against MEV

Mục tiêu là cung cấp các giao dịch có chọn lọc, có mức độ ưu tiên cao một cách kịp thời trên MAINCHAIN trong thời gian tắc nghẽn mạng. Các kênh ưu tiên có thể được xem như một dạng hợp đồng tương lai trên không gian khối và do đó là một loại tiền điện tử, một thuật ngữ được đặt ra như một phần của Dự án Chicago [61, 136]. Các kênh ưu tiên được dành riêng cho người khai thác để kích hoạt các dịch vụ cơ sở hạ tầng, chẳng hạn như oracles, chức năng quản trị cho hợp đồng, v.v.—không dành cho các hoạt động ở cấp độ người dùng thông thường như giao dịch tài chính. Trên thực tế, như được thiết kế ở đây, ưu tiên kênh được thực hiện bởi ít hơn 100% công suất khai thác trong mạng chỉ có thể cung cấp các giới hạn lỏng lẻo về thời gian giao hàng, ngăn cản việc sử dụng nó cho các hoạt động phụ thuộc nhiều vào tốc độ các mục tiêu như chạy trước. Hình 10: Kênh ưu tiên là sự đảm bảo của người khai thác M—hay nói chung hơn là một tập hợp các công cụ khai thác M—cho người dùng U rằng giao dịch τ của cô ấy sẽ được khai thác trong các khối D đưa vào mempool. SC hợp đồng có thể sử dụng giám sát DON để thực thi điều khoản dịch vụ của kênh. Kênh ưu tiên có dạng thỏa thuận giữa người khai thác hoặc tập hợp người khai thác (hoặc nhóm khai thác) M cung cấp kênh và người dùng U trả phí để truy cập. M đồng ý rằng khi U gửi giao dịch τ tới mempool (với bất kỳ giá gas nào,nhưng giới hạn gas đã được thỏa thuận trước), M sẽ đặt nó trên chuỗi trong các khối D tiếp theo.8 Ý tưởng này được mô tả dưới dạng sơ đồ trong Hình 10. Mô tả hợp đồng kênh ưu tiên: Một kênh ưu tiên có thể được thực hiện như một lai smart contract đại khái như sau. Chúng tôi để SC biểu thị logic trên MAINCHAIN và điều đó trên DON bởi người thực thi. SC chấp nhận khoản tiền gửi / cổ phần \(d from M and an advance payment \)p từ U. A DON người thực thi thực thi giám sát mempool, kích hoạt vị trí của giao dịch bởi U. Nó gửi thông báo thành công tới SC nếu U gửi giao dịch mà M khai thác một cách kịp thời và một thông báo lỗi trong trường hợp dịch vụ bị lỗi. SC gửi khoản thanh toán $p tới M với thông báo thành công và gửi tất cả số tiền còn lại, bao gồm $d, tới U nếu nó nhận được thông báo lỗi. Sau khi chấm dứt thành công, nó phát hành khoản tiền gửi $d cho M. Tất nhiên, công cụ khai thác M có thể cung cấp các kênh ưu tiên đồng thời cho nhiều người dùng và có thể mở kênh ưu tiên bằng U cho số lượng tin nhắn đã thỏa thuận trước. 4,5 Bảo quản bí mật DeFi / Hỗn hợp Ngày nay, DeFi ứng dụng [1] cung cấp rất ít hoặc không có tính bảo mật cho người dùng: Tất cả các giao dịch đều hiển thị trên chuỗi. Các cách tiếp cận dựa trên kiến thức không khác nhau, ví dụ: [149, 217], có thể cung cấp quyền riêng tư cho giao dịch và TEF đủ chung để hỗ trợ chúng. Nhưng những cách tiếp cận này không toàn diện và chẳng hạn, thường không che giấu được tài sản mà giao dịch dựa trên đó. Tập hợp rộng rãi các công cụ tính toán mà chúng tôi dự định hỗ trợ trong DONs sẽ cho phép quyền riêng tư theo một số cách khác nhau có thể lấp đầy những khoảng trống đó, giúp bổ sung cho việc đảm bảo quyền riêng tư của các hệ thống khác. Ví dụ: Mixicles, một công cụ bảo mật DeFi được đề xuất bởi Chainlink Các nhà nghiên cứu của Labs [135], có thể che giấu loại tài sản hỗ trợ một công cụ tài chính và rất phù hợp với DON khuôn khổ. Hỗn hợp được giải thích dễ dàng nhất về mặt sử dụng của chúng để nhận ra một hệ nhị phân đơn giản tùy chọn. Quyền chọn nhị phân là một công cụ tài chính trong đó hai người dùng, chúng ta sẽ tham khảo tại đây để biết tính nhất quán với [135] với tư cách là người chơi, đặt cược vào một sự kiện có hai khả năng kết quả, ví dụ: liệu một tài sản có vượt quá giá mục tiêu tại một thời điểm được chỉ định trước hay không. Ví dụ sau đây minh họa ý tưởng. Ví dụ 2. Alice và Bob là các bên tham gia quyền chọn nhị phân dựa trên giá trị của tài sản được gọi là Mã thông báo bong bóng của Carol (CBT). Alice đặt cược rằng CBT sẽ có giá thị trường ở mức tối thiểu 250 USD vào thời điểm T = trưa ngày 21/6/2025; Bob đặt cược ngược lại. Mỗi người chơi gửi 100 ETH theo thời hạn định trước. Người chơi có vị trí chiến thắng nhận được 200 ETH (tức là tăng 100 ETH). 8D tất nhiên phải đủ lớn để đảm bảo M có thể tuân thủ với xác suất cao. cho Chẳng hạn, nếu M kiểm soát 20% công suất khai thác trong mạng, nó có thể chọn D = 100, đảm bảo xác suất thất bại là ≈2 × 10−10, tức là nhỏ hơn một phần tỷ.Với Chainlink oracle mạng O hiện có, thật dễ dàng để triển khai một mạng thông minh hợp đồng SC thực hiện thỏa thuận trong Ví dụ 2. Hai người chơi mỗi bên gửi tiền 100 ETH trong SC. Một thời gian sau T, một truy vấn q được gửi đến O yêu cầu giá r của CBT tại thời điểm T. O gửi báo cáo r về mức giá này cho SC. SC sau đó gửi tiền cho Alice nếu r ≥250 và Bob nếu không. Tuy nhiên, cách tiếp cận này tiết lộ r trên chuỗi—làm cho việc này trở nên dễ dàng để người quan sát suy ra tài sản cơ bản của tùy chọn nhị phân. Trong thuật ngữ của Mixicles, sẽ rất hữu ích khi nghĩ về kết quả một cách khái niệm của SC dưới dạng Switch truyền giá trị nhị phân được tính toán dưới dạng vị từ chuyển đổi (r). Trong ví dụ của chúng tôi, switch(r) = 0 nếu r ≥250; với kết quả này, Alice thắng. Ngược lại switch(r) = 1 và Bob thắng. DON có thể nhận ra Mixicle cơ bản dưới dạng hợp đồng kết hợp bằng cách chạy một tệp thực thi exec tính toán switch(r) và báo cáo nó trên chuỗi cho SC. Chúng tôi hiển thị công trình này trong hình 11. Hình 11: Sơ đồ Mixicle cơ bản trong Ví dụ 2. Để cung cấp bí mật trên chuỗi cho báo cáo r và do đó, nội dung cơ bản của tùy chọn nhị phân, oracle sẽ gửi tới hợp đồng SC thông qua Chỉ chuyển đổi giá trị nhị phân switch(r). Chúng tôi chỉ định một bộ chuyển đổi ConfSwitch trong Phụ lục C.3 để giúp bạn dễ dàng đạt được điều này mục tiêu trong DON. Ý tưởng cơ bản đằng sau ConfSwitch khá đơn giản. Thay vì báo cáo giá trị r, ConfSwitch chỉ báo cáo giá trị chuyển đổi nhị phân switch(r). SC có thể được thiết kế để thực hiện thanh toán chính xác chỉ dựa trên switch(r) và chính switch(r) không tiết lộ thông tin nào về tài sản cơ bản—CBT trong ví dụ của chúng tôi. Ngoài ra, bằng cách đặt một bản mã vào (q, r) trên sổ cái được mã hóa bằng pkaud, khóa chung của kiểm toán viên, bộ điều hợp ConfSwitch tạo ra một quy trình kiểm tra bảo mật. Mixicle cơ bản mà chúng tôi đã chọn để mô tả đơn giản ở đây chỉ che giấu tài sản và đặt cược đằng sau tùy chọn nhị phân trong ví dụ của chúng tôi. Một Mixicle toàn diện [135] có thể cung cấp hai hình thức bảo mật. Nó che giấu những người quan sát: (1) Sự kiện gì người chơi đặt cược vào (tức là q và r) nhưng cũng có (2) Người chơi nào đã thắng cược. Vì Mixicles được thực thi trên MAINCHAIN nên một trong hai người chơi sẽ cần chuyển tiếp switch(r) từ DON sang MAINCHAIN hoặc có thể tạo một trình thực thi thực thi được

được kích hoạt ở đầu ra bởi ConfSwitch và gọi một bộ chuyển đổi khác để gửi switch(r) tới CHUỖI MAIN. Loại bảo mật tinh tế thứ ba cũng đáng được xem xét. Trong quá trình triển khai cơ bản của ConfSwitch, O đang chạy bộ điều hợp trên DON và do đó học được tài sản—CBT trong ví dụ của chúng tôi—và do đó là bản chất của quyền chọn nhị phân. Như đã thảo luận tuy nhiên, trong Phụ lục C.3, có thể sử dụng thêm DECO hoặc Town Crier để che giấu ngay cả thông tin này với O. Trong trường hợp này, O không biết thêm thông tin hơn là một người quan sát công khai của SC. Để biết thêm chi tiết về Mixicles, chúng tôi giới thiệu độc giả tới [135].

分散化によって実現される分散化サービス

オラクルネットワークス DONs の多用途性と、それらがどのように新しいサービスのホストを可能にするかを説明するには、次のようにします。 このセクションでは、DON ベースのアプリケーションの 5 つの例を示し、 それらを実現するハイブリッド契約: (1) クロスチェーン サービスの一形態である Proof of Reserves。 (2) エンタープライズ/レガシーシステムとのインターフェース、つまりミドルウェアベースのシステムの作成 最小限の要素で blockchain アプリケーションの開発を容易にする抽象化レイヤー blockchain 固有のコードまたは専門知識。 (3) 分散型アイデンティティ、ユーザーが次のことを可能にするツール 自分自身の身分証明書と資格情報を取得して管理する。 (4) 優先チャンネル、 重要なインフラストラクチャのトランザクションをタイムリーに含めることを保証するサービス (例: oracle) レポート) blockchain について。 (5) 機密保持 DeFi、つまり財務 参加当事者の機密データを隠すsmart contract。 ここで、私たちは

SC を使用してハイブリッド コントラクトの MAINCHAIN 部分を示し、DON を記述します。 コンポーネントを個別に、または実行可能ファイル exec として。 4.1 準備金の証明 多くのアプリケーションでは、blockchain 間で状態を中継すると便利です。あ このようなサービスの一般的な用途は、暗号通貨のラッピングです。ラッピングされたコインなど WBTC [15] は分散型金融 (DeFi) で人気の資産になりつつあるためです。彼らは 「ラップされた」バッキング資産をソース blockchain MAINCHAIN(1) にデポジットすることが含まれます。 そして、対応する token を別のターゲット blockchain MAINCHAIN(2) に作成します。 たとえば、WBTC は、Ethereum blockchain 上の ERC20 token であり、これに対応します。 Bitcoin blockchain の BTC へ。 MAINCHAIN(2) のコントラクトは MAINCHAIN(1) を直接認識できないため、 ラップされた資産のデポジットを報告するには、明示的または暗黙的に oracle に依存する必要があります。 smart contract の資産を作成し、プルーフ・オブ・リザーブと呼ばれることもあります。で WBTC [15] など、カストディアン BitGo は BTC を保持し、WBTC を発行します。 Chainlink ネットワークはプルーフ オブ リザーブ [76] を提供します。 DON 自体が準備金の証明を提供できます。ただし、DON では、次のことが可能です。 さらに進むために。 DON はシークレットを管理でき、適切なアダプターを使用することで、 任意のblockchainで取引できます。したがって、DON が動作する可能性があります。 多数のカストディアンの中の 1 人として、または単一の分散型カストディアンとして、 ラップされたアセット。これにより、DONs は、セキュリティを強化するプラットフォームとして機能します。 Proofs of Reserves を使用する既存のサービス。 たとえば、MAINCHAIN(1) が Bitcoin で、MAINCHAIN(2) が Ethereum であるとします。 MAINCHAIN(2) では、コントラクト SC がラップされた BTC を表す token を発行します。 DON BTC アドレス addr(1) を制御します DON。 BTC をラップするには、ユーザー U が X BTC を送信します。 アドレス(1) U アドレス(1)へ DON と MAINCHAIN(2)-address addr(2) U 。 DON モニター アドレス(1) DON アダプタ経由で MAINCHAIN(1) に接続します。 U のデポジットを観察すると、十分に高い確率で確認が得られ、アダプタを介して SC にメッセージを送信します。 メインチェーン(2)。このメッセージは、SC に addr(2) の X token を作成するように指示します。 U 。 U が X token を解放すると、その逆が起こります。 ただし、MAINCHAIN(1) では、 アドレス(1) DON は X BTC を addr(1) に送信します U (またはユーザーが要求した場合は別のアドレス)。 もちろん、これらのプロトコルは、直接ではなく交換機と連動するように適合させることができます。 ユーザーと一緒に。 4.2 エンタープライズ/レガシー システムとのインターフェース DON は、Proof の例のように、blockchain 間のブリッジとして機能します。 しかし、もう一つの目的は、保護区間の双方向の橋渡し役として機能することです。 blockchain およびレガシー システム [176] または blockchain のようなシステム (中央銀行など) デジタル通貨 [30]。 企業は、既存のシステムとネットワークを接続する際に多くの課題に直面しています。 以下を含む分散システムへのプロセス。• ブロックチェーンの俊敏性: ブロックチェーン システムは急速に変化します。企業は、blockchain の急速な新たな出現や人気の上昇に直面する可能性があります。 取引相手は取引を希望しているが、企業にはそれに関する権限がない。 既存のインフラストラクチャでのサポート。一般的に、blockchains のダイナミズムは 個々の企業が完全なエコシステムに遅れを取らないようにすることは困難です。 • ブロックチェーン固有の開発リソース: 多くの組織にとって、最先端のblockchain専門知識を雇用または育成することは、特に次のような観点から困難です。 敏捷性への挑戦。 • 秘密鍵の管理: blockchains または暗号通貨の秘密鍵を管理するには、従来のサイバーセキュリティとは異なる運用上の専門知識が必要です。 慣行であり、多くの企業は利用できません。 • 機密性: 企業は機密情報や専有情報を公開することを懸念しています。 チェーン上のデータ。 これらの問題のうち最初の 3 つに対処するには、開発者は DON を使用するだけで済みます。 エンタープライズ システムの読み取りまたは書き込みを可能にする安全なミドルウェア層として blockchain秒。 DON は、次のような詳細な技術的考慮事項を抽象化できます。 ガスダイナミクス、チェーンの再編成など、開発者とユーザーの両方に役立ちます。によって 合理化された blockchain インターフェイスをエンタープライズ システムに提供することで、DON は blockchain 対応のエンタープライズ アプリケーションの開発が大幅に簡素化され、blockchain 固有の開発リソースを取得または育成するという企業の負担が軽減されます。 DONs のこのような使用法は、エンタープライズ開発者が次のことを可能にするという点で特に魅力的です。 blockchain にほとんど依存しないスマート コントラクト アプリケーションを作成します。その結果、 DON がミドルウェアとして機能するように設定されている blockchain のセットが大きい場合、 企業ユーザーが簡単にアクセスできる blockchain のセットが大きくなります。開発者 最小限の変更で既存の blockchain から新しいアプリケーションにアプリケーションを移植できます 社内で開発されたアプリケーションに。 機密保持というさらなる問題に対処するために、開発者は、 この文書で紹介するツールは、DON アプリケーションをサポートするために導入される予定です。 これらには、DECO および Town Crier セクション 3.6.2 および機密保持が含まれます。 API の変更についてはセクション 7.1.2 で説明し、アプリケーション固有のいくつかのアプローチについてはこのセクションの残りの部分で説明します。これらのDON システムは次のことを提供できます。 エンタープライズ システムの状態を明らかにすることなく、高整合性のオンチェーン認証を行う 機密性の高いエンタープライズ ソース データがチェーン上に存在します。 4.3 分散型アイデンティティ 分散型アイデンティティは、ユーザーが次のことができるべきであるという概念の一般用語です。 サードパーティに依存するのではなく、独自の資格情報を取得して管理する そう。分散型資格情報は、所有者の属性または主張に対する証明書です。これらはしばしばクレームと呼ばれます。資格情報は、エンティティによってデジタル署名されます。 発行者は、権限を持ってクレームをユーザーに関連付けることができます。提案されているスキームのほとんどでは、 クレームは、分散型識別子 (DID)、つまり汎用識別子に関連付けられています。 特定のユーザー。資格情報は、ユーザーがその秘密鍵を保持する公開鍵にバインドされます。 したがって、ユーザーは自分の秘密鍵を使用して請求の所有を証明できます。 分散型アイデンティティとしての先見性は、既存のスキームと提案されたスキームです。例: [14、92、 129, 216] には 3 つの重大な制限があります。 • レガシー互換性の欠如: 既存の分散型 ID システムは、 発行者と呼ばれる当局のコミュニティが DID 認証情報を生成します。なぜなら 既存の Web サービスは通常、データにデジタル署名を行わないため、発行者が立ち上げる必要がある 特殊な目的のシステムとして。なぜなら、 分散型アイデンティティ エコシステムでは、卵が先か鶏が先かの問題が発生します。その他では つまり、発行者のエコシステムをどのようにブートストラップするかは不明です。 • 機能しないキー管理: 分散型 ID システムでは、ユーザーは次のことを行う必要があります。 秘密鍵の管理、暗号通貨の経験が示していること 実行不可能な負担になること。約 4,000,000 Bitcoin が被害を受けたと推定されています。 鍵管理の失敗 [194] により永久に失われ、多くのユーザーが 暗号資産を取引所 [193] と共有することにより、分散化が損なわれます。 • プライバシーを保護するシビル耐性の欠如: 投票、token 販売中の token の公平な割り当てなどのアプリケーションの基本的なセキュリティ要件は、次のとおりです。 ユーザーは複数の ID を主張できません。既存の分散型アイデンティティ提案では、そのようなことを実現するために、ユーザーが現実世界のアイデンティティを明らかにする必要があります。 シビル耐性により、重要なプライバシー保証が損なわれます。 ノードの委員会を組み合わせて使用することで、これらの問題に対処することが可能です。 DON 内で分散計算を実行し、DECO などのツールを使用する または、CanDID [160] と呼ばれるシステムに示されている Town Crier。 DECO または Town Crier は、設計により既存の Web サービスを変更せずに変えることができます 機密性を保持する資格情報の発行者に。これらにより、DON が関連するファイルをエクスポートできるようになります。 この目的のためのデータを認証情報に含める一方、機密データを隠す必要はありません。 資格情報に表示されます。 さらに、ユーザーのキー回復を容易にし、キー管理の問題に対処します。 問題として、DON を使用すると、ユーザーは秘密鍵を秘密共有形式で保存できるようになります。ユーザーは次のことができます DON 内のノードに証明することでキーを回復します。同様に、Town Crier または DECO - 所定の Web プロバイダーのセットを使用してアカウントにログインする機能 (例: ツイッター、グーグル、フェイスブック）。 Town Crier または DECO を使用する利点は、 OAUTH はユーザーのプライバシーです。これら 2 つのツールを使用すると、ユーザーは DON への暴露を回避できます。 Web プロバイダーの識別子。多くの場合、そこから現実世界の ID を導き出すことができます。 最後に、[160] に示すように、シビル耐性を提供するには、DON で次のことが可能です。 ユーザーの一意の実世界識別子のプライバシーを保護する変換を実行する (社会保障番号 (SSN) など) をユーザー登録時にオンチェーン識別子に変換します。これにより、システムは、次のような機密データを使用せずに重複した登録を検出できます。 SSN は個々の DON ノードに公開されます。7 DON は、外部の分散型 ID に代わってこれらのサービスのいずれかを提供できます 許可のないまたは許可された blockchain 上のシステム (例: Hyperledger のインスタンス) インディ [129]。 アプリケーション例: KYC: 分散型アイデンティティは、次の手段として有望です。 ユーザーの利便性を向上させながら、blockchains の金融アプリケーションの要件を合理化します プライバシー。解決に役立つ 2 つの課題は、マネーロンダリング防止 / 顧客確認 (AML / KYC) 規制に基づく認定とコンプライアンス義務です。 多くの国の AML 規制では、金融機関 (およびその他の企業) に対して、取引先の個人および企業の身元を確認し、確認することが求められています。 彼らは取引を実行します。 KYC は金融機関のコンポーネントの 1 つを形成します。 より広範な AML ポリシーには、通常、特にユーザーの行動の監視や資金の流れの監視も含まれます。 KYC には通常、何らかの形式 (例: ユーザーの顔の前に身分証明書をかざしてオンライン Web フォームに入力する ビデオセッションなど）。分散型認証情報の安全な作成と提示 原理的には、いくつかの点で有益な代替手段となり得る。すなわち、(1) KYC プロセスは、ユーザーと金融機関にとってより効率的になります。 資格情報が取得されれば、あらゆる金融機関にシームレスに提示できます。 (2) 侵害による個人情報の盗難の機会を減らすことで不正行為を減らす 個人識別情報 (PII) の流出およびビデオ検証中のなりすまし。そして (3) ユーザーがコントロールを保持できるため、金融機関における PII 侵害のリスクが軽減されます。 自分自身のデータの。 AMLコンプライアンス違反に対して金融機関が支払った数十億ドルの罰金と、多くの金融機関がKYCに年間数百万ドルを費やしていることを考慮すると、改善は金融機関にかなりの節約をもたらす可能性がある さらに言えば、消費者向け[196]。伝統的な金融セクターの動きが遅い一方で、 新しいコンプライアンス ツールを採用するために、DeFi システムでは [43] を採用するケースが増えています。 適用例: 担保不足のローン: ほとんどのDeFiアプリケーションは、 現在のサポート融資は、完全に担保された融資のみを組成しています。これらは融資です 融資額を超える仮想通貨資産を預けている借り手に。 最近、DeFi コミュニティで一般に過少担保ローンと呼ばれるものに関心が高まっています。対照的に、これらは対応する担保が設定されているローンです。 ローンの元本よりも価値が低いもの。担保不足のローン 従来の金融機関が行うローンによく似ています。依存するのではなく ローン返済の保証として預けられた担保に基づいて融資を行うのではなく、 借り手の信用履歴に基づく決定。 7この変換は分散擬似乱数関数 (PRF) に依存しています。担保不足のローンは、DeFi 融資市場において初期段階ではあるものの、成長を続けている部分を構成しています。彼らは伝統的な金融機関が採用しているようなメカニズムに依存しています。 法的契約 [91] などの機関。彼らの成長に不可欠な要件 従来の融資決定における重要な要素であるユーザーの信用力に関するデータを、強力な整合性を提供する方法で DeFi システムに提供できるようになります。 正しいデータの保証。 DON 対応の分散型 ID システムにより、借り手希望者は次のことが可能になります。 信用力を維持しながら、信頼性の高い認証情報を生成します。 機密情報の機密性。具体的には、借り手はこれらを生成できます 信頼できるオンライン ソースからの記録に基づく認証情報のみを公開しながら、 他の潜在的な機密データを公開することなく、DON によって証明されたデータ。のために たとえば、借り手は自分の信用スコアが 一連の信用調査機関は、彼女を明らかにすることなく、特定のしきい値 (例: 750) を超えます。 彼女の記録にある正確なスコアやその他のデータ。さらに、必要に応じて、そのような資格情報 匿名で生成できます。つまり、ユーザーの名前は機密データとして扱われます。 そして、それ自体は oracle ノードや分散認証情報に公開されません。資格情報 それ自体は、アプリケーションに応じてチェーンまたはオフチェーンで使用できます。 要約すると、借り手は自分の信用に関する重要な情報を貸し手に提供できます。 強い整合性を持ち、不必要で機密性の高い情報が漏洩するリスクのない履歴 データ。 借り手は、機密保持のためのその他のさまざまな認証情報を提供することもできます。 融資の決定に役立ちます。たとえば、資格情報は借り手の本人であることを証明できます。 次の例で示すように、(オフチェーン) 資産の所有。 アプリケーション例: 認定: 多くの管轄区域では、未登録証券を販売できる投資家の種類が制限されています。たとえば、米国では SEC 規則 D では、そのような投資機会に対して認定されるためには、 個人は 100 万ドルの純資産を所有しているか、特定の最低収入要件を満たしているか、特定の専門的資格を持っている必要があります [209, 210]。現在の認定 プロセスは煩雑で非効率的であり、多くの場合、 会計士、または同様の証拠。 分散型 ID システムにより、ユーザーは次の情報から資格情報を生成できます。 認定への準拠を証明する既存のオンライン金融サービス口座 規制を強化し、より効率的でプライバシーを保護した KYC プロセスを促進します。 の さらに、DECO と Town Crier のプライバシー保護特性により、これらのことが可能になります。 認証情報は、ユーザーの経済状況の詳細を直接明らかにすることなく、完全性が強力に保証されて生成されます。たとえば、ユーザーは資格情報を生成できます。 それ以上のことを明らかにすることなく、彼女が少なくとも100万ドルの純資産を持っていることを証明する 彼女の経済状況に関する情報。 4.4 優先チャンネル プライオリティ チャネルは、DON を使用して簡単に構築できる便利な新しいサービスです。彼らの

Diagram of basic Mixicle showing on-chain secrecy with private oracle reporting

Priority channel diagram showing a miner guarantee for transaction ordering to protect against MEV

目標は、厳選された優先度の高いトランザクションをメインチェーン上でタイムリーに配信することです ネットワークが混雑しているとき。優先チャネルは、次のような形式と見なすことができます。 ブロック空間上の先物契約、したがって暗号商品としての一部として造られた用語 プロジェクト・シカゴ [61, 136]。 優先チャネルは、特にマイナーがoracle、契約のガバナンス機能などのインフラストラクチャ サービスを有効にすることを目的としており、金融取引などの通常のユーザーレベルのアクティビティを対象とするものではありません。 実際、ここで設計されているように、優先順位は ネットワーク内のマイニング電力の 100% 未満によって実装されたチャネルは、 配信時間に緩やかな制限を設け、速度に大きく依存する用途での使用を防止します。 先制ゴールなど。 図 10: 優先チャネルはマイナー M による保証です。より一般的には、 マイナーのセット M - ユーザー U に、彼女のトランザクション τ が D ブロック内でマイニングされることを通知します。 mempool に含めるかどうか。契約 SC は、DON モニタリングを使用して、 チャンネルのサービス規約。 優先チャネルは、マイナーまたはマイナーのセット間の合意の形をとります。 チャネルを提供する（またはマイニングプール）M と、アクセス料金を支払うユーザー U です。 M は、U がトランザクション τ をメモリプールに送信するとき (任意のガス価格で、ただし、事前に合意されたガス制限）、M はそれを次の D ブロック内のチェーンに配置します。8 この概念を図 10 に概略的に示します。 優先チャネル契約の説明: 優先チャネルは、 ハイブリッド smart contract はおおよそ次のとおりです。 SC は MAINCHAIN 上のロジックを表すものとします。 そしてそれは exec による DON のものです。 SC は U.A からデポジット / ステーク \(d from M and an advance payment \)p を受け取ります DON 実行可能ファイル exec はメモリプールを監視し、トランザクションの配置時にトリガーします U によって、M がマイニングするトランザクションを U が送信すると、成功メッセージが SC に送信されます。 タイムリーな方法と、サービス障害の場合の障害メッセージ。 SC は成功メッセージを受け取って $p の支払いを M に送信し、残りの資金をすべて送信します。 $d を含み、失敗メッセージを受信した場合は U に送信されます。正常に終了すると、 M に $d のデポジットをリリースします。 もちろん、マイナー M は複数のユーザーに優先チャネルを同時に提供することもできます。 ユーザーは、事前に合意された数のメッセージに対して U を使用して優先チャネルを開くことができます。 4.5 機密保持 DeFi / Mixicles 現在、DeFi アプリケーション [1] は、ユーザーに対して機密性をほとんど、あるいはまったく提供していません。すべてのトランザクションはチェーン上で表示されます。さまざまなゼロ知識ベースのアプローチ、例: [149、217]、 トランザクションのプライバシーを提供でき、TEF はそれらをサポートするのに十分な汎用性を備えています。でも これらのアプローチは包括的ではなく、たとえば、通常、 トランザクションの基礎となる資産。 DONs で最終的にサポートする予定の広範な計算ツールのセットは、 このようなギャップを埋めるさまざまな方法でプライバシーを確保し、他のシステムのプライバシー保証を補完するのに役立ちます。たとえば、Chainlink 研究所の研究者 [135] によって提案された機密保持 DeFi 機器である Mixicles は、 金融商品を裏付ける資産タイプであり、DON に非常に自然に適合します。 フレームワーク。 ミクシクルは、単純なバイナリを実現するために使用するという観点から最も簡単に説明されます。 オプション。 バイナリー オプションは 2 人のユーザーが参加する金融商品です。 プレーヤーとしての [135] との一貫性については、ここを参照してください。2 つの可能性があるイベントに賭けます 結果、たとえば、事前に指定された時点で資産が目標価格を超えるかどうか。 次の例は、このアイデアを示しています。 例 2. アリスとボブは、資産の価値に基づくバイナリー オプションの当事者です。 キャロルのバブルトークン（CBT）と呼ばれます。アリスは、CBT の市場価格が になると賭けます。 2025 年 6 月 21 日の T = 正午時点で最低 250 米ドル。ボブは逆に賭けます。各プレイヤー 事前に指定された期限までに 100 ETH を入金します。勝ちポジションを持つプレイヤー 200 ETHを受け取ります（つまり、100 ETHを獲得します）。 もちろん、8D は、M が高い確率に準拠できることを保証するのに十分な大きさでなければなりません。 のために たとえば、M がネットワーク内のマイニング電力の 20% を制御している場合、D = 100 を選択する可能性があります。 故障確率は ≈2 × 10−10、つまり 10 億分の 1 未満です。既存の Chainlink oracle ネットワーク O を考慮すると、スマートなネットワークを実装するのは簡単です。 例 2 の合意を実現する契約 SC。2 人のプレーヤーがそれぞれ入金します。 SCで100ETH。 T の後のある時点で、クエリ q が O に送信され、商品の価格 r が要求されます。 時間 T.O の CBT は、この価格のレポート r を SC に送信します。その後、SC はアリスに送金します。 r ≥250 の場合はボブ、そうでない場合はボブ。ただし、このアプローチではチェーン上の r が明らかになり、簡単になります。 オブザーバーがバイナリー オプションの基礎となる資産を推測できるようにします。 Mixicles の用語では、結果を概念的に考えると役立ちます。 述語として計算されたバイナリ値を送信するスイッチに関する SC の スイッチ(r)。この例では、r ≥250 の場合は switch(r) = 0 になります。この結果を考えると、アリスが勝ちます。 それ以外の場合は、switch(r) = 1 となり、ボブが勝ちます。 DON は、実行可能ファイルを実行することで、基本的な Mixicle をハイブリッド コントラクトとして実現できます。 switch(r) を計算し、それをチェーン上で SC に報告する exec。この構造を示します 図11に示す。 図 11: 例 2 の基本的な Mixicle の図。 レポート r、つまりバイナリー オプションの基礎となる資産を、oracle が バイナリ値スイッチのみを介して SC を契約します (r)。 これを簡単に実現できるアダプター ConfSwitch を付録 C.3 で指定します。 DONでゴール。 ConfSwitch の基本的な考え方は非常にシンプルです。報告する代わりに 値 r の場合、ConfSwitch はバイナリ スイッチ値 switch(r) のみを報告します。 SCは可能です switch(r) のみ、および switch(r) 自体に基づいて正しい支払いを行うように設計されています。 原資産 (この例では CBT) に関する情報は明らかにされません。さらに、 pkaud で暗号化された台帳上の (q, r) に暗号文を配置することにより、 アダプターの ConfSwitch は、機密性を保持する監査証跡を作成します。 ここでの説明を簡単にするために選択した基本的な Mixicle は、 この例では、バイナリー オプションの背後にある資産と賭け金です。本格的な Mixicle [135] は次のことができます。 2 つの形式の機密保持を提供します。それは観察者からは次のことを隠します: (1) どのような出来事が起こったか プレイヤーは（つまり、q と r）だけでなく、（2）どのプレイヤーが賭けに勝ったかにも賭けます。 Mixicles は MAINCHAIN 上で実行されるため、どちらかのプレイヤーが中継する必要があります。 DON から MAINCHAIN に switch(r) するか、実行可能 exec が作成される可能性があります。

ConfSwitch による出力でトリガーされ、別のアダプターを呼び出してスイッチ(r) を送信します。 メインチェーン。 3 番目の微妙な種類の機密保持も考慮する価値があります。 ConfSwitch の基本的な実装では、O は DON でアダプターを実行しているため、 資産 (この例では CBT)、つまりバイナリー オプションの性質です。議論したように ただし、付録 C.3 では、さらに DECO または Town Crier を使用して、 この情報さえも O から隠します。この場合、O はそれ以上の情報を知りません。 SCの公的オブザーバーよりも。 Mixicles の詳細については、[135] を参照してください。

Dịch vụ sắp xếp công bằng

Một dịch vụ quan trọng mà chúng tôi mong đợi DON sẽ cung cấp nhằm tận dụng khả năng kết nối mạng, tính toán và lưu trữ của họ được gọi là Dịch vụ tuần tự công bằng (FSS). Mặc dù FSS có thể được xem đơn giản là một ứng dụng được triển khai trong khuôn khổ DON nhưng chúng tôi nhấn mạnh đây là một dịch vụ mà chúng tôi tin rằng sẽ có nhu cầu cao trên toàn thế giới. blockchains và chúng tôi mong đợi mạng Chainlink sẽ tích cực hỗ trợ. Khi được thực thi trên các mạng blockchain công cộng, nhiều ứng dụng DeFi ngày nay tiết lộ thông tin mà người dùng có thể khai thác vì lợi ích riêng của họ, tương tự như các loại rò rỉ nội bộ và các cơ hội thao túng đang tràn lan trong thị trường [64, 155]. Thay vào đó, FSS mở đường hướng tới một hệ sinh thái DeFi công bằng. FSS giúp các nhà phát triển xây dựng các hợp đồng DeFi được bảo vệ khỏi sự thao túng thị trường do rò rỉ thông tin. Với những vấn đề chúng tôi nêu dưới đây, FSS là đặc biệt hấp dẫn đối với các dịch vụ lớp 2 và phù hợp trong khuôn khổ các dịch vụ đó mà chúng ta thảo luận ở Phần 6. Thử thách: Trong các hệ thống không được phép hiện có, các giao dịch được sắp xếp hoàn toàn theo quyết định của thợ mỏ. Trong các mạng được phép, các nút validator có thể phát huy tác dụng sức mạnh như nhau. Đây là một hình thức tập trung nhất thời phần lớn không được công nhận trong các hệ thống phi tập trung khác. Người khai thác có thể (tạm thời) kiểm duyệt các giao dịch của mình lợi ích riêng [171] hoặc sắp xếp lại chúng để tối đa hóa lợi ích của chính nó, một khái niệm được gọi là giá trị có thể khai thác được (MEV) [90]. Thuật ngữ MEV hơi gây nhầm lẫn: Nó không đề cập đến chỉ với giá trị mà người khai thác có thể nắm bắt: Một số MEV có thể được người dùng thông thường nắm bắt. Tuy nhiên, do thợ đào có nhiều quyền lực hơn người dùng thông thường nên MEV đại diện cho giới hạn trên về lượng giá trị mà bất kỳ thực thể nào có thể có được thông qua việc sắp xếp lại đối nghịch. và chèn giao dịch bổ sung. Ngay cả khi thợ mỏ yêu cầu giao dịch một cách đơn giản dựa trên phí (gas), không cần thao túng, người dùng có thể tự mình thao túng giá gas để tạo thuận lợi cho các giao dịch của họ so với những giao dịch kém tinh vi hơn. Daian và cộng sự. [90] ghi lại và định lượng các cách mà bot (không phải thợ mỏ) thực hiện lợi dụng động lực học khí theo cách gây hại cho người dùng hệ thống DeFi ngày nay và cách thức MEV thậm chí còn đe dọa sự ổn định của lớp đồng thuận cơ bản trong blockchain. Các ví dụ khác về thao túng lệnh giao dịch thường xuyên xuất hiện, ví dụ: [50, 154].Các phương thức xử lý giao dịch mới như rollups là một cách tiếp cận rất hứa hẹn đối với các vấn đề mở rộng quy mô của blockchains thông lượng cao. Tuy nhiên, họ không đề cập đến vấn đề MEV Thay vào đó, họ chuyển nó sang thực thể tạo ra rollup. Đó thực thể, dù là người vận hành smart contract hay người dùng cung cấp (zk-)rollup với bằng chứng hợp lệ, có quyền ra lệnh và chèn các giao dịch. Nói cách khác, rollups hoán đổi MEV lấy REV: Giá trị có thể trích xuất tổng hợp. MEV ảnh hưởng đến các giao dịch sắp tới đã được gửi tới mempool nhưng chưa được cam kết trên chuỗi. Thông tin về các giao dịch như vậy được phổ biến rộng rãi có sẵn trong mạng. Người khai thác, validator và người tham gia mạng thông thường có thể do đó khai thác kiến thức này và tạo ra các giao dịch phụ thuộc. Ngoài ra, người khai thác và validator có thể ảnh hưởng đến thứ tự của các giao dịch mà họ thực hiện và khai thác điều này để có lợi cho mình. Vấn đề ảnh hưởng quá mức của lãnh đạo đến việc sắp xếp giao dịch theo sự đồng thuận các giao thức đã được biết đến trong tài liệu từ những năm 1990 [71, 190], nhưng chưa thỏa mãn các giải pháp đã được hiện thực hóa trong thực tế cho đến nay [97]. Lý do chính là các giải pháp được đề xuất – ít nhất cho đến gần đây – không thể dễ dàng tích hợp với các giải pháp công cộng. blockchains, vì chúng dựa vào nội dung của các giao dịch được giữ bí mật cho đến sau đó thứ tự của chúng đã được xác định. Tổng quan về Dịch vụ tuần tự công bằng (FSS): DONs sẽ cung cấp các công cụ để phân cấp việc đặt hàng giao dịch và triển khai nó theo chính sách được chỉ định bởi một cơ quan phụ thuộc người tạo hợp đồng, lý tưởng nhất là người tạo ra hợp đồng công bằng và không mang lại lợi ích cho những người muốn Thao tác đặt hàng giao dịch. Nói chung, các công cụ này tạo thành FSS. FSS bao gồm ba thành phần. Đầu tiên là giám sát các giao dịch. Trong FSS, Các nút oracle trong O đều giám sát bộ nhớ của MAINCHAIN và cho phép (nếu muốn) gửi các giao dịch ngoài chuỗi thông qua một kênh chuyên biệt. Thứ hai là trình tự các giao dịch. Các nút trong giao dịch theo thứ tự O cho một hợp đồng dựa trên theo chính sách được xác định cho hợp đồng đó. Thứ ba là đăng tải các giao dịch. Sau khi các giao dịch được sắp xếp, các nút trong O cùng nhau gửi các giao dịch đến chuỗi chính. Những lợi ích tiềm năng của FSS bao gồm: • Tính công bằng của đơn hàng: FSS bao gồm các công cụ giúp nhà phát triển đảm bảo rằng các giao dịch đầu vào của một hợp đồng cụ thể được sắp xếp theo cách không gây ra sự thiếu công bằng lợi thế cho người dùng có nguồn lực tốt và/hoặc hiểu biết về kỹ thuật. Chính sách đặt hàng có thể được chỉ định cho mục đích này. • Giảm hoặc loại bỏ rò rỉ thông tin: Bằng cách đảm bảo rằng những người tham gia mạng không thể khai thác kiến thức về các giao dịch sắp tới, FSS có thể giảm bớt hoặc loại bỏ các cuộc tấn công như chạy trước dựa trên thông tin có sẵn trong mạng trước khi giao dịch được thực hiện. Ngăn chặn việc khai thác như vậy rò rỉ đảm bảo rằng các giao dịch đối nghịch phụ thuộc vào bản gốc đang chờ xử lý giao dịch không thể vào sổ cái trước khi giao dịch ban đầu được thực hiện.• Giảm chi phí giao dịch: Bằng cách loại bỏ yêu cầu của người chơi về tốc độ gửi giao dịch của họ tới smart contract, FSS có thể giảm đáng kể chi phí xử lý giao dịch. • Thứ tự ưu tiên: FSS có thể tự động ưu tiên đặc biệt cho các giao dịch quan trọng đặt hàng. Ví dụ: để ngăn chặn các cuộc tấn công trực tiếp chống lại oracle báo cáo, ví dụ: [79], FSS có thể chèn báo cáo oracle vào luồng giao dịch hồi tố. Mục tiêu bao quát của FSS trong DONs là trao quyền cho DeFi người sáng tạo để thực hiện công bằng hệ thống tài chính, nghĩa là các hệ thống không mang lại lợi ích cho người dùng (hoặc thợ mỏ) cụ thể hơn người khác trên cơ sở tốc độ, kiến thức nội bộ hoặc khả năng thực hiện kỹ thuật thao túng. Trong khi một khái niệm chung chung và sắc nét về sự công bằng là khó nắm bắt, thì sự công bằng hoàn hảo trong mọi ý nghĩa hợp lý đều không thể đạt được, FSS nhằm mục đích cung cấp cho các nhà phát triển một giải pháp mạnh mẽ bộ công cụ để họ có thể thực thi các chính sách giúp đáp ứng mục tiêu thiết kế của họ cho DeFi. Chúng tôi lưu ý rằng mặc dù mục tiêu chính của FSS là hoạt động như một dịch vụ giải trình tự công bằng cho MAINCHAIN mà DON nhắm tới, một số mong muốn công bằng tương tự như FSS đảm bảo cũng có thể phù hợp với các giao thức (phi tập trung) được chạy giữa DON bữa tiệc. Do đó, FSS có thể được xem rộng hơn như một dịch vụ được cung cấp bởi một tập hợp con trong số DON nút có trình tự khá hợp lý, không chỉ các giao dịch được gửi bởi người dùng MAINCHAIN mà còn cả các giao dịch (tức là tin nhắn) được chia sẻ giữa các nút DON khác. Trong phần này, chúng tôi sẽ tập trung chủ yếu vào mục tiêu sắp xếp thứ tự các giao dịch MAINCHAIN. Tổ chức phần: Trong Phần 5.1, chúng tôi mô tả hai ứng dụng cấp cao thúc đẩy thiết kế FSS: ngăn chặn việc chạy trước các báo cáo oracle và ngăn chặn chạy trước các giao dịch của người dùng. Sau đó chúng tôi cung cấp thêm chi tiết về thiết kế của FSS trong Phần 5.2. Phần 5.3 mô tả các ví dụ về đảm bảo trật tự công bằng và các biện pháp để đạt được chúng. Cuối cùng, Phần 5.4 và Phần 5.5 thảo luận về các mối đe dọa ở cấp độ mạng đối với các chính sách và phương tiện đó để giải quyết chúng, tương ứng với tình trạng tràn mạng và Sybil các cuộc tấn công. 5.1 Vấn đề chạy trước Để giải thích các mục tiêu và thiết kế của FSS, chúng tôi mô tả hai dạng chung của hoạt động chạy trước các cuộc tấn công và những hạn chế của các giải pháp hiện có. Chạy trước minh họa một lớp về các cuộc tấn công đặt hàng giao dịch: Có một số cuộc tấn công liên quan như chạy ngược và xen kẽ (chạy trước và chạy sau) [237] mà chúng tôi không đề cập đến ở đây, nhưng FSS nào cũng giúp giải quyết. 5.1.1 Oracle chạy trước Với vai trò truyền thống là cung cấp dữ liệu ngoài chuỗi cho blockchain ứng dụng, oracles trở thành mục tiêu tự nhiên cho các cuộc tấn công trực diện.Hãy xem xét mẫu thiết kế phổ biến về việc sử dụng oracle để cung cấp các nguồn cấp dữ liệu giá khác nhau đến trao đổi trên chuỗi: định kỳ (giả sử mỗi giờ), oracle thu thập dữ liệu giá cho các tài sản khác nhau và gửi chúng tới một hợp đồng trao đổi. Các giao dịch dữ liệu giá này đưa ra các cơ hội chênh lệch giá rõ ràng: Ví dụ: nếu báo cáo oracle mới nhất liệt kê giá cao hơn nhiều cho một số nội dung, đối thủ có thể chạy trước báo cáo oracle tới mua tài sản và bán lại ngay sau khi báo cáo của oracle được xử lý. Giảm tốc độ và định giá hồi tố: Một giải pháp tự nhiên cho vấn đề chạy trước oracle là ưu tiên đặc biệt cho các báo cáo của oracle so với các giao dịch khác. cho ví dụ: oracle báo cáo có thể được gửi với mức phí cao để khuyến khích người khai thác xử lý họ đầu tiên. Nhưng điều này sẽ không ngăn cản việc chạy trước nếu cơ hội kinh doanh chênh lệch giá cao, nó cũng không thể ngăn chặn sự chênh lệch giá của chính những người khai thác. Do đó, một số sàn giao dịch đã phải sử dụng đến việc triển khai các “tốc độ tăng tốc” nặng nề hơn, chẳng hạn như xếp hàng các giao dịch của người dùng cho một số khối trước khi xử lý. chúng hoặc điều chỉnh giá trở về trước khi có báo cáo oracle mới. Nhược điểm của các giải pháp này là chúng làm tăng thêm độ phức tạp cho việc thực hiện trao đổi, tăng yêu cầu lưu trữ và do đó chi phí giao dịch, đồng thời làm gián đoạn trải nghiệm người dùng vì việc trao đổi tài sản chỉ được xác nhận sau một khoảng thời gian đáng kể. Cõng: Trước khi chuyển sang FSS, chúng ta thảo luận về việc cõng, một cách khá đơn giản và giải pháp tinh tế cho vấn đề chạy trước oracle. Nó không áp dụng cho địa chỉ Tuy nhiên, chạy trước trong các tình huống khác. Tóm lại, thay vì gửi báo cáo định kỳ tới hợp đồng trên chuỗi, oracles xuất bản các báo cáo đã ký mà người dùng thêm vào giao dịch của họ khi mua hoặc bán tài sản trên chuỗi. Sau đó, sàn giao dịch chỉ cần kiểm tra xem báo cáo có hợp lệ và mới không (ví dụ: oracle có thể ký một phạm vi khối mà báo cáo hợp lệ) và trích xuất nguồn cấp dữ liệu giá có liên quan từ nó. Cách tiếp cận đơn giản này có một số ưu điểm so với cách “tăng tốc” ở trên cách tiếp cận: (1) Hợp đồng trao đổi không cần giữ trạng thái nguồn cấp giá, điều này sẽ dẫn đến chi phí giao dịch thấp hơn; (2) Vì các báo cáo oracle được đăng trên chuỗi khi cần thiết, oracles có thể tạo ra các cập nhật thường xuyên hơn (ví dụ: mỗi phút), do đó giảm thiểu cơ hội chênh lệch giá từ việc chạy trước một báo cáo9; (3) Giao dịch có thể được xác thực ngay lập tức vì chúng luôn bao gồm nguồn cấp dữ liệu giá mới. Tuy nhiên, cách tiếp cận này không hoàn hảo. Đầu tiên, giải pháp cõng này đặt trách nhiệm của người dùng sàn giao dịch là tìm nạp các báo cáo oracle cập nhật và đính kèm chúng vào giao dịch. Thứ hai, mặc dù việc cõng làm giảm thiểu cơ hội kinh doanh chênh lệch giá nhưng nó không thể ngăn chặn hoàn toàn chúng mà không ảnh hưởng đến tính tồn tại của hợp đồng trên chuỗi. Thật vậy, nếu một oracle báo cáo có hiệu lực cho đến khi khối số n nào đó, sau đó giao dịch được gửi tới khối n + 1 sẽ yêu cầu một báo cáo hợp lệ mới. Do sự chậm trễ cố hữu trong việc truyền bá báo cáo từ oracle tới người dùng, báo cáo mới hợp lệ cho khối n + 1 sẽ có 9 Kinh doanh chênh lệch giá chỉ có giá trị nếu chênh lệch có thể khai thác được trong giá tài sản vượt quá chênh lệch không liên quan phí cần thiết để mua và bán tài sản, ví dụ: phí do người khai thác và sàn giao dịch thu.được công bố một khoảng thời gian trước khi khối n + 1 được khai thác, chẳng hạn tại khối n −k, do đó tạo ra một chuỗi k khối trong đó tồn tại cơ hội chênh lệch giá trong thời gian ngắn. Chúng tôi bây giờ hãy mô tả cách FSS khắc phục những hạn chế này. Ưu tiên oracle báo cáo với FSS: FSS có thể giải quyết oracle chạy trước vấn đề bằng cách xây dựng dựa trên giải pháp hỗ trợ ở trên nhưng đẩy mạnh thêm công việc tăng cường các giao dịch với oracle báo cáo cho Mạng Oracle phi tập trung. Ở mức cao, các nút oracle thu thập các giao dịch dành cho trao đổi trên chuỗi, đồng ý về nguồn cấp giá theo thời gian thực và đăng nguồn cấp giá cùng với các giao dịch đã thu thập lên hợp đồng chuỗi chính. Về mặt khái niệm, người ta có thể coi cách tiếp cận này như một “phân nhóm giao dịch tăng cường dữ liệu”, trong đó oracle đảm bảo rằng giao dịch được cập nhật nguồn cấp dữ liệu giá luôn được thêm vào các giao dịch. Các giải pháp FSS có thể được triển khai một cách minh bạch cho người dùng sàn giao dịch và với những thay đổi tối thiểu đối với logic hợp đồng, như chúng tôi mô tả chi tiết hơn trong Phần 5.2. Đảm bảo các báo cáo oracle mới luôn được ưu tiên hơn các giao dịch của người dùng chỉ là một ví dụ của chính sách đặt hàng mà FSS có thể áp dụng và thực thi. Chính sách của FSS nhằm đảm bảo trật tự sự công bằng được mô tả tổng quát hơn ở Phần 5.3. 5.1.2 Giao dịch người dùng chạy trước Bây giờ chúng ta chuyển sang chạy trước trong các ứng dụng chung, trong đó phương pháp bảo vệ ở trên không hoạt động. Vấn đề có thể được nắm bắt rộng rãi thông qua kịch bản sau: Kẻ tấn công nhìn thấy một số giao dịch tx1 của người dùng được gửi vào mạng P2P và tiêm vào giao dịch đối nghịch tx2 của chính nó, do đó tx2 được xử lý trước tx1 (ví dụ: bằng cách thanh toán phí giao dịch cao hơn). Ví dụ, kiểu chạy trước này phổ biến ở các bot khai thác cơ hội chênh lệch giá trong DeFi hệ thống [90] và đã ảnh hưởng đến người dùng các ứng dụng phi tập trung khác nhau [101]. Thiết lập trật tự công bằng giữa các giao dịch được xử lý trên blockchain sẽ giải quyết được vấn đề này. Cơ bản hơn, việc xem chi tiết tx1 đôi khi còn không cần thiết và biết về sự tồn tại đơn thuần của nó có thể cho phép kẻ thù chiếm ưu thế trước tx1 thông qua nó. sở hữu tx2 và lừa gạt người dùng vô tội đã tạo ra tx1. Ví dụ, người dùng có thể được biết là giao dịch một tài sản cụ thể vào thời điểm thường xuyên. Ngăn chặn các cuộc tấn công như vậy đòi hỏi các biện pháp giảm thiểu cũng tránh rò rỉ siêu dữ liệu [62]. Một số giải pháp cho vấn đề này tồn tại, nhưng chúng gây ra sự chậm trễ và những lo ngại về khả năng sử dụng. Từ đơn hàng mạng đến đơn hàng cuối cùng với FSS: Cơ hội đi trước phát sinh do các hệ thống hiện tại không có cơ chế để đảm bảo rằng thứ tự trong đó các giao dịch xuất hiện trên chuỗi tôn trọng thứ tự của các sự kiện và luồng thông tin bên ngoài mạng. Điều này thể hiện sự cố phát sinh từ những thiếu sót trong việc triển khai ứng dụng (ví dụ: nền tảng giao dịch) trên blockchain. Lý tưởng nhất là người ta sẽ đảm bảo rằng các giao dịch được cam kết trên blockchain theo đúng thứ tự như trước đây được tạo và gửi tới mạng P2P của blockchain. Nhưng vì mạng blockchain

Fair Sequencing Services general schematic showing transaction flow from users through DON to main chain

được phân phối thì không thể nắm bắt được thứ tự như vậy. Do đó FSS giới thiệu các cơ chế để bảo vệ khỏi những hành vi vi phạm sự công bằng phát sinh chỉ vì sự phân bổ bản chất của mạng blockchain. 5.2 Chi tiết FSS Hình 12: Mempool hợp lý với hai đường dẫn giao dịch khác nhau: trực tiếp và dựa trên mempool. Hình 12 thể hiện sơ đồ chung của FSS. Để đảm bảo tính công bằng, DON cung cấp FSS phải can thiệp vào luồng giao dịch khi chúng tham gia MAINCHAIN. Có thể cần phải điều chỉnh đối với khách hàng, đối với smart contract trên MAINCHAIN ​​hoặc đối với cả hai. Ở mức độ cao, việc xử lý các giao dịch bằng FSS có thể được chia thành ba các giai đoạn được mô tả dưới đây: (1) Giám sát giao dịch; (2) Trình tự giao dịch; và (3) Đăng tải giao dịch. Tùy thuộc vào phương thức đặt hàng được sử dụng để sắp xếp trình tự giao dịch, cần có các bước giao thức bổ sung, như được mô tả trong phần tiếp theo. 5.2.1 Xử lý giao dịch Giám sát giao dịch: Chúng tôi hình dung ra hai cách tiếp cận khác nhau để FSS giám sát giao dịch của người dùng dành cho một smart contract cụ thể, trực tiếp và dựa trên mempool: • Trực tiếp: Cách tiếp cận trực tiếp đơn giản nhất về mặt khái niệm nhưng đòi hỏi phải thay đổi khách hàng người dùng để các giao dịch được gửi trực tiếp đến Oracle phi tập trungCác nút mạng, thay vì các nút của chuỗi chính. DON thu thập giao dịch của người dùng hướng đến một smart contract SC cụ thể và sắp xếp chúng dựa trên về một số chính sách đặt hàng. DON sau đó gửi các giao dịch đã đặt hàng tới smart contract trên chuỗi chính. Một số cơ chế đặt hàng cũng yêu cầu cách tiếp cận trực tiếp vì người dùng tạo giao dịch phải sử dụng mật mã bảo vệ nó trước khi gửi nó đến FSS. • Dựa trên Mempool: Để tạo điều kiện thuận lợi cho việc tích hợp FSS với các máy khách cũ, DON có thể sử dụng Dịch vụ Mempool (MS) để giám sát mempool của chuỗi chính và thu thập giao dịch. Truyền trực tiếp có thể là cách thực hiện được ưu tiên cho nhiều hợp đồng, và chúng tôi tin rằng nó sẽ khá thực tế trong nhiều trường hợp. Chúng tôi thảo luận ngắn gọn về cách các DApp hiện tại có thể được sửa đổi ở mức tối thiểu để hỗ trợ truyền trực tiếp trong khi vẫn duy trì trải nghiệm tốt cho người dùng. Chúng tôi mô tả các phương pháp tiếp cận sử dụng Ethereum và MetaMask [6] vì đây là những lựa chọn phổ biến nhất hiện nay, nhưng các kỹ thuật được đề cập sẽ mở rộng sang các chuỗi và ví khác. Ethereum gần đây Đề xuất cải tiến, “EIP-3085: Ví thêm Ethereum phương thức RPC chuỗi” [100], sẽ giúp dễ dàng nhắm mục tiêu các chuỗi Ethereum tùy chỉnh (sử dụng ID CHAIN khác với của MAINCHAIN để ngăn chặn các cuộc tấn công lặp lại) từ MetaMask và các ví dựa trên trình duyệt khác. Sau khi triển khai đề xuất này, DApp đang tìm cách sử dụng DON chỉ cần thêm một lệnh gọi phương thức vào giao diện người dùng của họ để có thể truyền trực tiếp giao dịch với bất kỳ DON nào có API tương thích với Ethereum. Trong khi đó, “EIP-712: Ethereum đã nhập dữ liệu có cấu trúc hash nhập và ký” [49] cung cấp một chút giải pháp thay thế có liên quan nhiều hơn nhưng đã được triển khai rộng rãi, nơi người dùng DApp có thể sử dụng MetaMask để ký dữ liệu có cấu trúc chỉ định giao dịch DON. DApp có thể gửi dữ liệu có cấu trúc đã được ký này vào DON. Cuối cùng, chúng tôi lưu ý rằng các phương pháp kết hợp cũng có thể thực hiện được. Ví dụ, di sản khách hàng có thể tiếp tục gửi giao dịch vào mempool của chuỗi chính, nhưng điều quan trọng là các giao dịch (ví dụ: báo cáo oracle) được gửi trực tiếp đến DON nút (cụ thể là tập hợp các nút cung cấp oracle báo cáo chẳng hạn như cập nhật nguồn cấp dữ liệu giá và tập hợp các nút việc cung cấp FSS có thể trùng lặp hoặc giống hệt nhau). Trình tự giao dịch: Mục đích chính của FSS là đảm bảo rằng các giao dịch của người dùng được sắp xếp theo chính sách được xác định trước. Bản chất của chính sách này sẽ tùy thuộc vào nhu cầu của ứng dụng và các loại lệnh giao dịch không công bằng mà nó nhằm mục đích ngăn chặn. Vì FSS trên DON có khả năng xử lý dữ liệu và duy trì trạng thái cục bộ, họ có thể áp đặt chính sách sắp xếp thứ tự tùy ý dựa trên thông tin được có sẵn tại oracles. Các chính sách đặt hàng cụ thể và việc triển khai chúng sẽ được thảo luận sau trong Phần 5.3.Đăng giao dịch: Sau khi thu thập và sắp xếp các giao dịch của người dùng, nhận trực tiếp từ người dùng hoặc được thu thập từ mempool, DON sẽ gửi các giao dịch này đến chuỗi chính. Do đó, các tương tác của DON với chuỗi chính vẫn được duy trì tùy thuộc vào thứ tự giao dịch (có khả năng không công bằng) được quản lý bởi các thợ mỏ của chuỗi chính. Để khai thác lợi ích của việc đặt hàng giao dịch phi tập trung, mục tiêu thông minh do đó, hợp đồng SC phải được thiết kế để đối xử với DON như một công dân “hạng nhất”. Chúng tôi phân biệt hai cách tiếp cận: • Hợp đồng chỉ DON: Tùy chọn thiết kế đơn giản nhất là có chuỗi chính thông minh hợp đồng SC chỉ chấp nhận các giao dịch đã được xử lý bởi DON. Cái này đảm bảo rằng smart contract xử lý các giao dịch theo thứ tự được đề xuất bởi DON, nhưng trên thực tế hạn chế smart contract hoạt động trong hệ thống dựa trên ủy ban (tức là ủy ban DON hiện có quyền liên tục để xác định đặt hàng và bao gồm các giao dịch). • Hợp đồng hai lớp: Thiết kế được ưu tiên, chi tiết hơn có chuỗi chính thông minh hợp đồng SC chấp nhận các giao dịch có nguồn gốc từ cả DON và từ kế thừa người dùng,10 nhưng đặt những "gờ giảm tốc" truyền thống đối với các giao dịch không được DON xử lý. Ví dụ: các giao dịch từ DON có thể được xử lý ngay lập tức, trong khi các giao dịch kế thừa được smart contract “đệm” cho một khoảng thời gian nhất định. Các cơ chế tiêu chuẩn khác để ngăn chặn việc chạy trước chẳng hạn như các kế hoạch tiết lộ cam kết hoặc VDF [53] cũng có thể được áp dụng cho các kế hoạch cũ giao dịch. Điều này đảm bảo rằng các giao dịch theo thứ tự DON được xử lý trong mệnh lệnh đã được thống nhất mà không trao cho DON quyền kiểm duyệt không mong muốn giao dịch. Do việc FSS áp dụng thứ tự giao dịch yêu cầu các giao dịch phải được tổng hợp “ngoài chuỗi”, nên giải pháp này được kết hợp một cách tự nhiên với các kỹ thuật tổng hợp khác nhằm giảm chi phí xử lý trên chuỗi. Ví dụ, sau khi thu thập và đặt hàng các giao dịch, DON có thể gửi các giao dịch này đến chuỗi chính dưới dạng "giao dịch theo đợt" duy nhất (ví dụ: rollup), do đó làm giảm giao dịch tổng hợp phí. Thực thi lệnh giao dịch: Dù ở thiết kế chỉ DON hay thiết kế hai lớp, chuỗi chính smart contract SC và DON phải được đồng thiết kế để đảm bảo rằng thứ tự giao dịch của DON được duy trì. Ở đây cũng vậy, chúng tôi hình dung khác nhau tùy chọn thiết kế: • Số thứ tự: DON có thể thêm số thứ tự vào mỗi giao dịch và gửi các giao dịch này vào mempool của chuỗi chính. chính 10Nếu việc giám sát giao dịch của DON dựa trên mempool thì các giao dịch kế thừa phải được phân biệt với các giao dịch DON để chúng không bị DON thu thập, ví dụ: thông qua một thẻ đặc biệt được nhúng vào giao dịch hoặc bằng cách chỉ định một mức giá gas cụ thể, ví dụ: DON giao dịch có gas giá dưới một ngưỡng nhất định.chuỗi smart contract SC bỏ qua các giao dịch đến “không theo trình tự”. Chúng tôi lưu ý rằng trong cài đặt này, người khai thác chuỗi chính có thể quyết định bỏ qua DON đặt hàng giao dịch, do đó làm cho giao dịch thất bại. Có thể bằng cách giữ trạng thái (đắt) để SC thực thi thứ tự giao dịch chính xác, phần nào tương tự như cách TCP đệm các gói không đúng thứ tự cho đến khi các gói bị thiếu được đã nhận được. • Giao dịch nonce: Đối với nhiều blockchain và đặc biệt đối với Ethereum, Cách tiếp cận đánh số thứ tự ở trên có thể tận dụng giao dịch tích hợp nonces để buộc chuỗi chính smart contract SC xử lý các giao dịch theo trình tự. Tại đây, các nút DON gửi giao dịch đến chuỗi chính thông qua một tài khoản chuỗi chính duy nhất, được bảo vệ bằng khóa được chia sẻ giữa các nút DON. Tài khoản của giao dịch nonce đảm bảo rằng các giao dịch được khai thác và xử lý theo đúng thứ tự. • Tổng hợp các giao dịch: DON có thể tổng hợp nhiều giao dịch trong rollup (hoặc trong một gói tương tự như rollup). Chuỗi chính smart contract cần phải được được thiết kế để xử lý các giao dịch tổng hợp như vậy. • Tổng hợp các giao dịch bằng proxy chuỗi chính: Ở đây, DON tương tự gói các giao dịch thành một “giao dịch meta” cho chuỗi chính, nhưng dựa vào một proxy tùy chỉnh smart contract để giải nén các giao dịch và chuyển tiếp chúng tới hợp đồng mục tiêu SC. Kỹ thuật này có thể hữu ích cho khả năng tương thích cũ. Siêu giao dịch hoạt động giống như rollup nhưng khác ở chỗ chúng bao gồm một giao dịch không nén danh sách các giao dịch được đăng một lần lên chuỗi chính. Thiết kế cuối cùng có ưu điểm là hỗ trợ liền mạch các giao dịch của người dùng bản thân họ được ủy quyền thông qua hợp đồng chuỗi chính trước khi đạt được mục tiêu của DON hợp đồng SC. Ví dụ: hãy xem xét một người dùng gửi giao dịch đến một số ví hợp đồng, sau đó sẽ gửi một giao dịch nội bộ tới SC. Chỉ định một trình tự số lượng giao dịch như vậy sẽ rất phức tạp, trừ khi hợp đồng ví của người dùng được được thiết kế đặc biệt để chuyển tiếp số thứ tự với mọi giao dịch nội bộ tới SC. Tương tự, các giao dịch nội bộ như vậy không thể dễ dàng tổng hợp thành siêu giao dịch được gửi trực tiếp đến SC. Chúng tôi thảo luận thêm về những cân nhắc thiết kế cho các giao dịch ủy quyền dưới đây. 5.2.2 Tính nguyên tử của giao dịch Cuộc thảo luận của chúng ta cho đến nay đã ngầm giả định rằng các giao dịch tương tác với một trên chuỗi smart contract (ví dụ: người dùng gửi yêu cầu mua tới một sàn giao dịch). Tuy nhiên, trong các hệ thống như Ethereum, một giao dịch có thể bao gồm nhiều giao dịch nội bộ, ví dụ: một smart contract gọi một hàm trong một hợp đồng khác. Dưới đây, chúng tôi mô tả hai chiến lược cấp cao để sắp xếp các giao dịch “nhiều hợp đồng”, trong khi duy trì tính nguyên tử của giao dịch (tức là chuỗi hành động được quy định bởi tất cả các giao dịch đều được thực hiện theo đúng thứ tự hoặc hoàn toàn không).Tính nguyên tử mạnh: Giải pháp đơn giản nhất là áp dụng FSS, như được mô tả ở trên, trực tiếp cho toàn bộ giao dịch “nhiều hợp đồng”. Nghĩa là, người dùng gửi giao dịch của họ vào mạng và FSS giám sát, sắp xếp và đăng các giao dịch này lên chuỗi chính. Cách tiếp cận này đơn giản về mặt kỹ thuật nhưng có một hạn chế tiềm ẩn: Nếu người dùng giao dịch tương tác với hai hợp đồng SC1 và SC2 đều muốn tận dụng công bằng các dịch vụ sắp xếp thứ tự thì chính sách sắp xếp thứ tự của hai hợp đồng này phải nhất quán. Nghĩa là, với hai giao dịch tx1 và tx2 khác nhau mà mỗi giao dịch tương tác với cả SC1 và SC2, không được xảy ra trường hợp chính sách của SC1 đặt hàng tx1 trước tx2 trong khi chính sách của SC2 lại quy định thứ tự ngược lại. Đối với phần lớn các kịch bản quan tâm, chúng tôi hình dung rằng các chính sách trình tự được áp dụng bởi các hợp đồng khác nhau sẽ nhất quán. Ví dụ: cả SC1 và SC2 có thể muốn các giao dịch được sắp xếp theo thời gian đến gần đúng của chúng trong mempool, và SC1 có thể muốn một số báo cáo oracle nhất định luôn được gửi trước. Như sau đó oracle báo cáo các giao dịch không tương tác với SC2, các chính sách đều nhất quán. Tính nguyên tử yếu: Nói chung, FSS có thể được áp dụng ở cấp độ cá nhân giao dịch nội bộ. Xét các giao dịch có dạng tx = { ˜txpre, ˜txSC, ˜txpost}, bao gồm một số giao dịch ban đầu (các) giao dịch ˜txpre, dẫn đến một giao dịch nội bộ ˜txSC tới SC, do đó phát hành (các) giao dịch nội bộ ˜txpost. Chính sách giải trình tự của SC có thể xác định cách thức giao dịch nội bộ ˜txSC phải được sắp xếp theo các giao dịch khác được gửi tới SC, nhưng để ngỏ thứ tự tuần tự cho txpre vàtxpost. Do bản chất của việc xử lý giao dịch trong các hệ thống như Ethereum, việc phát triển dịch vụ tuần tự hướng tới các giao dịch nội bộ cụ thể không hề đơn giản. Với hợp đồng SC được thiết kế đặc biệt, điều này có thể được thực hiện như sau: 1. Giao dịch tx được gửi vào mạng và được khai thác (không có bất kỳ trình tự nào được thực hiện bởi FSS). ˜txpre ban đầu được thực thi và gọi ˜txSC. 2. SC không thực thi txSC và trả về. 3. FSS giám sát các giao dịch nội bộ tới SC, sắp xếp chúng và gửi lại chúng tới SC (tức là bằng cách gửi giao dịch ˜txSC trực tiếp đến SC). 4. SC xử lý các giao dịchtxSC nhận được từ FSS và phát hành các giao dịch nội bộ txpost phát sinh từtxSC. Với cách tiếp cận này, các giao dịch không được thực hiện hoàn toàn nguyên tử (tức là giao dịch gốc giao dịch tx được chia thành nhiều giao dịch trên chuỗi), nhưng thứ tự của giao dịch nội bộ được bảo tồn. Giải pháp này đòi hỏi một số hạn chế về thiết kế. Ví dụ: ‘txpre không thể giả sử rằng ˜txSC và ˜txpost sẽ được thực thi. Hơn nữa, SC nên được thiết kế sao cho thực hiện các giao dịch ˜txSC và ˜txpost thay mặt cho một người dùng nhất định, ngay cả khi họđược gửi bởi FSS. Vì những lý do này, giải pháp “Tính nguyên tử mạnh” chi tiết hơn ở trên có thể thích hợp hơn trong thực tế. Để tôn trọng sự phụ thuộc phức tạp hơn, liên quan đến nhiều giao dịch và các giao dịch nội bộ tương ứng của họ, bộ lập lịch giao dịch của FSS có thể chứa các chức năng phức tạp giống với các chức năng được tìm thấy trong các trình quản lý giao dịch của quan hệ những người quản lý cơ sở dữ liệu. 5.3 Trình tự giao dịch công bằng Ở đây chúng ta thảo luận về hai khái niệm về tính công bằng trong trình tự giao dịch và các triển khai tương ứng, có thể được FSS nhận ra: tính công bằng của trật tự dựa trên chính sách do FSS áp đặt và bảo toàn quan hệ nhân quả, đòi hỏi các phương pháp mã hóa bổ sung trong FSS. Trật tự-công bằng: Công bằng trật tự là một khái niệm về sự công bằng tạm thời trong các giao thức đồng thuận lần đầu tiên được giới thiệu chính thức bởi Kelkar et al. [144]. Kelkar và cộng sự. nhằm đạt được một hình thức chính sách tự nhiên trong đó các giao dịch được thực hiện được sắp xếp dựa trên thời gian chúng được nhận lần đầu tiên bởi DON (hoặc mạng P2P, trong trường hợp FSS dựa trên mempool). Tuy nhiên, trong một hệ thống phi tập trung, khác nhau các nút có thể thấy các giao dịch đến theo thứ tự khác nhau. Thiết lập một trật tự tổng thể trên tất cả các giao dịch chính là vấn đề được giải quyết bằng giao thức đồng thuận cơ bản CHUỖI MAIN. Kelkar và cộng sự. [144] do đó đưa ra một khái niệm yếu hơn có thể đạt được với sự trợ giúp của Mạng Oracle phi tập trung, được gọi là “sự công bằng theo thứ tự khối”. Nó nhóm các giao dịch mà DON đã nhận được trong một khoảng thời gian thành một “chặn” và chèn tất cả các giao dịch của khối một cách đồng thời và ở cùng một vị trí (tức là chiều cao) vào MAINCHAIN. Do đó, chúng được sắp xếp cùng nhau và phải có thể thực thi được song song mà không tạo ra bất kỳ xung đột nào giữa chúng. Nói một cách đại khái, tính công bằng trật tự phát biểu rằng nếu một phần lớn các nút nhìn thấy giao dịch τ1 trước τ2, thì τ1 sẽ được sắp xếp trước hoặc trong cùng khối với τ2. Bằng cách áp đặt một cách thô thiển như vậy mức độ chi tiết của lệnh giao dịch, cơ hội cho các cuộc tấn công chạy trước và các cuộc tấn công liên quan đến lệnh khác sẽ giảm đi đáng kể. Kelkar và cộng sự. đề xuất một họ giao thức có tên là Aequitas [144], địa chỉ các mô hình triển khai khác nhau, bao gồm cài đặt mạng đồng bộ, đồng bộ một phần và không đồng bộ. Các giao thức Aequitas áp đặt chi phí liên lạc đáng kể so với sự đồng thuận cơ bản BFT và do đó không lý tưởng để sử dụng thực tế. Tuy nhiên, chúng tôi tin rằng các biến thể thực tế của Aequitas sẽ xuất hiện và có thể được sử dụng để giải trình tự giao dịch trong FSS và các ứng dụng khác. Một số sơ đồ liên quan có đã được đề xuất có ít chủ nghĩa hình thức đi kèm hơn và các đặc tính yếu hơn, ví dụ: [36, 151, 236], nhưng hiệu suất thực tế tốt hơn. Những kế hoạch này có thể được hỗ trợ trong FSS cũng vậy. Cũng cần lưu ý rằng thuật ngữ “công bằng” xuất hiện ở nơi khác trong blockchain văn học với một ý nghĩa khác, cụ thể là sự công bằng trong ý nghĩa cơ hội chocông cụ khai thác tỷ lệ thuận với tài nguyên đã cam kết của họ [106, 181] hoặc cho validators tính theo cơ hội bình đẳng [153]. Bảo toàn nhân quả: Cách tiếp cận được biết đến rộng rãi nhất để ngăn chặn việc chạy trước và các hành vi vi phạm trật tự khác trong các nền tảng phân tán dựa vào mật mã. kỹ thuật. Đặc điểm chung của chúng là ẩn dữ liệu giao dịch, đợi đến khi trật tự ở lớp đồng thuận đã được thiết lập và tiết lộ dữ liệu giao dịch sau để xử lý. Điều này duy trì trật tự nhân quả giữa các giao dịch được thực hiện được thực thi bởi blockchain. Các khái niệm bảo mật và giao thức mật mã có liên quan đã được phát triển đáng kể trước sự ra đời của blockchains [71, 190]. Các điều kiện bảo mật của “quan hệ nhân quả đầu vào” [190] và “bảo toàn quan hệ nhân quả” [71, 97] yêu cầu chính thức rằng không có thông tin nào về giao dịch được biết đến trước khi vị trí của giao dịch này trong trật tự toàn cầu được xác định. Kẻ thù không được phép suy ra bất kỳ thông tin nào cho đến thời điểm đó, dưới dạng mật mã. giác quan mạnh mẽ. Người ta có thể phân biệt bốn kỹ thuật mật mã để bảo toàn quan hệ nhân quả: • Giao thức tiết lộ cam kết [29, 142, 145]: Thay vì công bố giao dịch rõ ràng, chỉ có cam kết mật mã đối với giao dịch được phát đi. Sau khi tất cả các giao dịch đã cam kết nhưng bị ẩn đã được đặt hàng (vào đầu blockchain hệ thống trên chính MAINCHAIN, nhưng ở đây là bởi FSS), người gửi phải mở cam kết và tiết lộ dữ liệu giao dịch trong một khoảng thời gian định trước. Sau đó, mạng sẽ xác minh rằng việc mở có đáp ứng được cam kết trước đó hay không. các nguồn gốc của phương pháp này có từ trước khi blockchains ra đời. Mặc dù nó đặc biệt đơn giản nhưng cách tiếp cận này có những hạn chế đáng kể và không dễ áp ​​dụng vì hai lý do. Đầu tiên, vì chỉ có cam kết tồn tại ở cấp độ giao thức đặt hàng nên ngữ nghĩa của giao dịch không thể được xác nhận trong quá trình đồng thuận. Một chuyến khứ hồi bổ sung cho khách hàng được yêu cầu. Tuy nhiên, nghiêm trọng hơn, cân nhắc khả năng không có sự mở cửa nào có thể bao giờ đến, điều này có thể dẫn đến một cuộc tấn công từ chối dịch vụ. Hơn nữa, nó thật khó để xác định liệu phần mở đầu có hợp lệ trong một cách nhất quán, phân tán hay không theo cách này bởi vì tất cả những người tham gia phải đồng ý về việc liệu thời điểm khai mạc đã đến thời gian. • Các giao thức tiết lộ cam kết có quá trình khôi phục bị trì hoãn [145]: Một thách thức với Cách tiếp cận cam kết tiết lộ là khách hàng có thể cam kết thực hiện một giao dịch theo cách suy đoán và chỉ tiết lộ nó sau này nếu các giao dịch tiếp theo mang lại lợi nhuận. A biến thể gần đây của phương pháp tiết lộ cam kết cải thiện khả năng phục hồi chống lại điều này loại hành vi sai trái. Đặc biệt, giao thức TEX [145] giải quyết vấn đề này sử dụng một cách tiếp cận thông minh trong đó các giao dịch được mã hóa bao gồm khóa giải mã có thể đạt được bằng cách tính toán hàm trễ có thể kiểm chứng (VDF) [53, 221]. Nếu một khách hàng không giải mã được giao dịch của mình kịp thời, những người khác trong hệ thống sẽ giải mã nó thay mặt cô ấy bằng cách giải một câu đố mật mã có độ khó vừa phải.• Mã hóa ngưỡng [71, 190]: Phương pháp này khai thác rằng DON có thể thực hiện hoạt động ngưỡng mật mã. Giả sử FSS duy trì mã hóa công khai khóa pkO và oracle chia sẻ khóa riêng tương ứng với nhau. Sau đó, khách hàng mã hóa các giao dịch theo pkO và gửi chúng đến FSS. Đơn đặt hàng FSS giao dịch trên DON, sau đó giải mã chúng và cuối cùng đưa chúng vào MAINCHAIN ​​theo thứ tự cố định. Do đó, mã hóa đảm bảo rằng việc đặt hàng được không dựa trên nội dung giao dịch mà chính dữ liệu đó có sẵn khi cần thiết. Phương pháp này ban đầu được đề xuất bởi Reiter và Birman [190] và sau đó được Cachin et al cải tiến. [71], nơi nó được tích hợp với sự đồng thuận được phép giao thức. Công việc gần đây hơn đã khám phá việc sử dụng mật mã ngưỡng như một cơ chế mức đồng thuận cho các thông báo chung [33, 97] và cho các tính toán chung với dữ liệu được chia sẻ [41]. So với các giao thức tiết lộ cam kết, mã hóa ngưỡng ngăn chặn các cuộc tấn công từ chối dịch vụ đơn giản (mặc dù cần phải cẩn thận do chi phí tính toán của việc giải mã). Nó cho phép DON hoạt động tự động, theo tốc độ riêng của nó và không cần chờ đợi những hành động tiếp theo của khách hàng. Các giao dịch có thể được xác thực ngay sau khi chúng được giải mã. Hơn nữa, khách hàng mã hóa tất cả các giao dịch bằng một khóa cho DON và kiểu giao tiếp vẫn giống như các kiểu khác giao dịch. Quản lý khóa ngưỡng một cách an toàn và với các nút thay đổi trong Tuy nhiên, O có thể gây thêm khó khăn. • Chia sẻ bí mật đã cam kết [97]: Thay vì mã hóa dữ liệu giao dịch theo khóa được giữ bởi DON, khách hàng cũng có thể chia sẻ bí mật khóa đó cho các nút trong O. Sử dụng sơ đồ chia sẻ bí mật kết hợp, an toàn về mặt tính toán, giao dịch được mã hóa đầu tiên bằng mật mã đối xứng với khóa ngẫu nhiên. Chỉ có khóa đối xứng tương ứng mới được chia sẻ và bản mã được gửi tới DON. Máy khách phải gửi một khóa chia sẻ tới mỗi nút trong O bằng một tin nhắn được mã hóa riêng. Các bước giao thức còn lại tương tự như với ngưỡng mã hóa, ngoại trừ dữ liệu giao dịch được giải mã bằng cơ chế đối xứng thuật toán sau khi xây dựng lại khóa cho mỗi giao dịch từ các chia sẻ của nó. Phương pháp này không yêu cầu thiết lập hoặc quản lý hệ thống mật mã khóa công khai được liên kết với DON. Tuy nhiên, khách hàng phải nhận thức được các nút trong O và liên lạc trong bối cảnh an toàn với từng người trong số họ, nơi đặt thêm gánh nặng cho khách hàng. Mặc dù các phương pháp mật mã cung cấp sự bảo vệ hoàn toàn chống lại thông tin rò rỉ từ các giao dịch đã gửi lên mạng, chúng không che giấu siêu dữ liệu. cho ví dụ: địa chỉ IP hoặc địa chỉ Ethereum của người gửi vẫn có thể được sử dụng bởi một đối thủ để thực hiện các cuộc tấn công chạy trước và các cuộc tấn công khác. Tăng cường quyền riêng tư khác nhau các kỹ thuật được triển khai ở lớp mạng, ví dụ: [52, 95, 107] hoặc lớp giao dịch, ví dụ: [13, 65] sẽ cần thiết để hoàn thành mục tiêu này. Tác động của một phần cụ thể siêu dữ liệu, cụ thể là giao dịch được gửi đến hợp đồng nào, có thể được che giấu (một phần)thông qua việc ghép nhiều hợp đồng trên cùng một DON. Che giấu mật mã bản thân các giao dịch cũng không ngăn cản việc ưu tiên các giao dịch do lỗi DON nút thông đồng với người gửi giao dịch. Đảm bảo tính nhân quả được đảm bảo bởi các giao thức mật mã bổ sung cho các đảm bảo về tính công bằng trật tự cho bất kỳ chính sách nào và chúng tôi dự định khám phá sự kết hợp của cả hai phương pháp, nếu điều này có thể. Nếu đối thủ không thể đạt được lợi thế đáng kể từ quan sát siêu dữ liệu, các giao thức bảo toàn quan hệ nhân quả an toàn có thể được sử dụng cùng với cũng là một cách tiếp cận đặt hàng ngây thơ. Ví dụ: nút oracle có thể ghi giao dịch tới L ngay khi họ nhận được chúng mà không bị trùng lặp. Các giao dịch sau đó sẽ được được sắp xếp theo sự xuất hiện của chúng trên L và sau đó được giải mã. Chúng tôi cũng có kế hoạch xem xét việc sử dụng TEE như một cách giúp thực thi trật tự công bằng; cho ví dụ: Tesseract [44] có thể được xem là đạt được một dạng trật tự nhân quả, nhưng một được củng cố bởi khả năng của TEE xử lý các giao dịch ở dạng rõ ràng trong khi duy trì tính bảo mật của chúng. 5,4 Những cân nhắc về lớp mạng Cho đến nay, mô tả của chúng tôi về FSS chủ yếu tập trung vào vấn đề thực thi thứ tự cuối cùng của các giao dịch khớp với thứ tự được quan sát của chúng trong mạng. Sau đây, chúng tôi xem xét các vấn đề công bằng có thể phát sinh ở chính lớp mạng. Các nhà giao dịch tần số cao trong các thị trường điện tử thông thường đầu tư đáng kể tài nguyên để có được tốc độ mạng vượt trội [64] và các nhà giao dịch trong các sàn giao dịch tiền điện tử thể hiện hành vi tương tự [90]. Tốc độ mạng mang lại lợi thế cả về mặt giám sát các giao dịch của các bên khác và gửi các giao dịch cạnh tranh. Một biện pháp khắc phục được triển khai trong thực tế và phổ biến trong cuốn sách Flash Boys [155] là “tăng tốc” được giới thiệu ban đầu trong sàn giao dịch IEX [128] và sau đó ở sàn giao dịch khác trao đổi [179] (với kết quả hỗn hợp [19]). Cơ chế này áp đặt độ trễ (350 micro giây trong IEX) khi tiếp cận thị trường, nhằm mục đích vô hiệu hóa các lợi thế trong tốc độ. Bằng chứng thực nghiệm, ví dụ: [128], hỗ trợ hiệu quả của nó trong việc giảm giao dịch nhất định chi phí cho các nhà đầu tư thông thường. FSS có thể được sử dụng đơn giản để thực hiện một cơ chế bất đối xứng giảm tốc độ—làm trì hoãn các giao dịch đến. Budish, Cramton và Shim [64] cho rằng việc khai thác lợi thế về tốc độ là không thể tránh khỏi trong các thị trường thời gian liên tục và tranh luận về một biện pháp khắc phục mang tính cơ cấu trong hình thức thị trường đấu giá hàng loạt. Nhưng cách tiếp cận này chưa được áp dụng rộng rãi trong các nền tảng giao dịch hiện có. Các hệ thống giao dịch thông thường được tập trung hóa, thường nhận giao dịch thông qua một kết nối mạng duy nhất. Ngược lại, trong một hệ thống phi tập trung, có thể quan sát việc truyền bá giao dịch từ nhiều điểm thuận lợi. Do đó, có thể quan sát các hành vi như tràn mạng trong mạng P2P. chúng tôi dự định để khám phá các cách tiếp cận lớp mạng đối với FSS giúp các nhà phát triển chỉ định các chính sách cấm các hành vi mạng không mong muốn như vậy.5,5 Chính sách công bằng ở cấp độ thực thể Tính công bằng trong trật tự và tính nhân quả an toàn nhằm mục đích thực thi trật tự đối với các giao dịch tôn trọng thời điểm chúng được tạo và lần đầu tiên được gửi lên mạng. Hạn chế của khái niệm công bằng này là nó không ngăn chặn được các cuộc tấn công mà đối thủ đạt được lợi thế bằng cách làm tràn ngập một hệ thống có nhiều giao dịch, một chiến lược được quan sát ngoài tự nhiên như một cách để thực hiện việc theo dõi giao dịch hiệu quả trong token doanh số [159] và để tạo ra tắc nghẽn dẫn đến việc thanh lý các vị trí nợ thế chấp (CDP) [48]. Nói cách khác, sự công bằng trong trật tự đảm bảo sự công bằng đối với các giao dịch chứ không phải đối với người chơi. Như được hiển thị trong hệ thống CanDID [160], có thể sử dụng các công cụ oracle như DECO hoặc Town Crier kết hợp với một ủy ban gồm các nút (chẳng hạn như DON) để đạt được nhiều hình thức kháng Sybil khác nhau trong khi vẫn bảo vệ quyền riêng tư. Người dùng có thể đăng ký danh tính và cung cấp bằng chứng về tính độc đáo của họ mà không tiết lộ danh tính. Thông tin xác thực chống lại âm thanh cung cấp một cách tiếp cận khả thi để làm phong phú thêm việc đặt hàng giao dịch chính sách theo cách có thể hạn chế cơ hội cho các cuộc tấn công tràn ngập. Ví dụ, một token chương trình giảm giá chỉ có thể cho phép một giao dịch cho mỗi người dùng đã đăng ký, trong trường hợp đăng ký yêu cầu bằng chứng về tính duy nhất của mã định danh quốc gia, chẳng hạn như Số An sinh Xã hội. Cách tiếp cận như vậy không phải là hoàn hảo nhưng có thể chứng tỏ là một chính sách hữu ích để giảm thiểu các cuộc tấn công tràn ngập giao dịch.

公正な順序付けサービス

DONs が提供すると予想される、ネットワーキング、計算、ストレージ機能を活用した重要なサービスの 1 つは、Fair Sequencing Services (FSS) と呼ばれます。 FSS は単に DON フレームワーク内で実現されるアプリケーションとして見なされるかもしれませんが、私たちは FSS を、あらゆる分野で需要が高いと思われるサービスとして強調しています。 blockchains、Chainlink ネットワークが積極的にサポートすることが期待されます。 パブリック blockchain ネットワーク上で実行すると、今日の DeFi アプリケーションの多くが ユーザーが自分の利益のために悪用できる情報を明らかにする。 既存の組織に蔓延している内部関係者の漏洩や操作の機会の種類 市場[64、155]。その代わりに、FSS は公平な DeFi エコシステムへの道を開きます。 FSS 開発者が市場操作から保護されたDeFi契約を構築するのに役立ちます 情報漏洩によるもの。以下で強調する問題を考慮すると、FSS は レイヤ 2 サービスにとって特に魅力的であり、そのようなサービスのフレームワーク内に適合します これについてはセクション 6 で説明します。 課題: 既存のパーミッションレス システムでは、トランザクションは完全に順序付けされます 鉱山労働者の裁量で。許可されたネットワークでは、validator ノードが影響を与える可能性があります。 同じ力。これは、ほとんど認識されていない一時的な集中化の一形態です。 それ以外の場合は分散システム。マイナーはトランザクションを（一時的に）検閲することができます。 [171] 自身の利益を最大化するか、自身のゲインを最大化するためにそれらを並べ替えます。これは、採掘可能値 (MEV) [90] と呼ばれる概念です。 MEV という用語は少し欺瞞的です。つまり、MEV を指すものではありません。 マイナーがキャプチャできる値のみ: 一部の MEV は一般ユーザーがキャプチャできます。 ただし、マイナーは通常のユーザーよりも大きな権限を持っているため、MEV は、あらゆるエンティティが敵対的な並べ替えを通じて取得できる価値の量の上限を表します。 および補完的なトランザクションの挿入。マイナーが単純にトランザクションを注文する場合でも、 料金（ガス）に基づいて、操作することなく、ユーザー自身がガス価格を操作できます 洗練されていない取引よりも取引を有利にするため。 大安ら。 [90] ボット (マイナーではない) が実行する方法を文書化して定量化します。 今日のDeFiシステムのユーザーに害を及ぼすガス力学の利点とその方法 MEV は、blockchain の基礎となるコンセンサス層の安定性さえ脅かします。 トランザクション注文操作の他の例は定期的に表示されます ([50, 154] など)。rollups などの新しいトランザクション処理メソッドは、非常に有望なアプローチです 高スループット blockchain のスケーリングの問題に対処します。しかし、彼らは言及していない MEVの問題。代わりに、rollup を生成するエンティティにそれをシフトします。それ smart contract のオペレーターであるか、(zk-)rollup に提供するユーザーであるかに関係なく、エンティティ 有効性の証明であり、トランザクションを注文して挿入する権限があります。つまり、rollups MEV と REV: ロールアップ抽出可能な値を交換します。 MEV は、メモリプールに送信された今後のトランザクションに影響します。 しかし、まだチェーン上にコミットされていません。このような取引に関する情報は広範に提供されます。 ネットワークで利用可能です。マイナー、validator、および一般のネットワーク参加者は、 したがって、この知識を利用して依存トランザクションを作成します。さらに、マイナーと validator は、コミットするトランザクションの順序に影響を与える可能性があります。 自分自身を攻撃し、これを自分たちの利益のために利用します。 合意に基づく取引順序に対するリーダーによる不当な影響の問題 プロトコルは 1990 年代から文献で知られていました [71, 190] が、満足のいくものはありませんでした。 解決策はこれまでに実際に実現されています [97]。 主な理由は、提案されたソリューションが、少なくともごく最近までは、公共のソリューションに容易に統合できなかったことです。 blockchains、トランザクションの内容がその後まで機密に保たれることに依存しているため 彼らの順番は決まっています。 Fair Sequencing Services (FSS) の概要: DONs は、トランザクションの順序を分散化し、依存者によって指定されたポリシーに従って実装するためのツールを提供します。 契約作成者、理想的には公平で、契約を希望する関係者に有利にならないもの トランザクションの順序を操作します。これらのツールは集合的に FSS を構成します。 FSS には 3 つのコンポーネントが含まれています。 1 つ目はトランザクションの監視です。 FSSでは、 O の oracle ノードは両方とも MAINCHAIN のメモリプールを監視し、(必要に応じて) 許可します 特殊なチャネルを介したオフチェーンでのトランザクションの送信。 2 つ目はトランザクションの順序付けです。 O のノードは依存コントラクトのトランザクションを注文します その契約に対して定義されたポリシーに従って。 3つ目は取引の転記です。 トランザクションが注文された後、O のノードは共同でトランザクションを メインチェーン。 FSS の潜在的な利点は次のとおりです。 • 注文の公平性: FSS には、開発者がトランザクションを確実に実行できるように支援するツールが含まれています。 特定の契約への入力は、不公平を生じない方法で命令される。 リソースが豊富なユーザーや技術的に精通したユーザーにとっては有利です。注文ポリシー この目的のために指定できます。 • 情報漏洩の削減または排除: ネットワーク参加者が今後のトランザクションに関する知識を悪用できないようにすることで、FSS を軽減または排除できます。 入手可能な情報に基づいたフロントランニングのような攻撃を排除します。 トランザクションがコミットされる前にネットワークにアクセスします。そのような悪用を防止する 漏洩により、元の保留中のトランザクションに依存する敵対的なトランザクションが確実に実行されます。 元のトランザクションがコミットされるまでは、トランザクションを台帳に入力することはできません。• トランザクションコストの削減: プレイヤーが提出する際のスピードの必要性を排除することにより、 トランザクションを smart contract に制限することで、FSS はトランザクション処理のコストを大幅に削減できます。 • 優先順位: FSS は重要なトランザクションに自動的に特別な優先順位を与えることができます。 注文すること。たとえば、oracle に対する前線攻撃を防ぐため レポート (例: [79])、FSS はトランザクションのストリームに oracle レポートを挿入できます 遡及的に。 DONs における FSS の包括的な目標は、DeFi クリエイターが公平性を実現できるようにすることです。 金融システム、つまり、特定のユーザー（またはマイナー）に利益をもたらさないシステム スピード、内部知識、または技術的な実行能力に基づいて他の人よりも優れている 操作。公平性の明確な一般的な概念はとらえどころがなく、完璧な公平性は FSS は、開発者に強力な機能を提供することを目的としています。 DeFi の設計目標を達成するのに役立つポリシーを適用できるツール セット。 FSS の主な目標は、公平な順序付けサービスとして機能することですが、 DON がターゲットとする MAINCHAIN、FSS と同じ公平性の要求の一部 保証は、複数のユーザー間で実行される (分散型) プロトコルにも適している可能性があります。 DON パーティー。したがって、FSS はサブセットによって提供されるサービスとしてより広く見ることができます。 MAINCHAIN のユーザーによって送信されたトランザクションだけでなく、公正に順序付けする DON ノード 他の DON ノード間で共有されるトランザクション (つまり、メッセージ) も同様です。このセクションでは、 ここでは主に、MAINCHAIN トランザクションの順序付けという目標に焦点を当てます。 セクションの構成: セクション 5.1 では、FSS の設計を動機付ける 2 つの高レベルのアプリケーションについて説明します。oracle レポートのフロントランニングの防止と、レポートのフロントランニングの防止です。 ユーザートランザクションのフロントランニング。次に、FSS の設計についてさらに詳しく説明します。 セクション5.2に記載されています。セクション 5.3 では、公正な注文の保証と手段の例について説明します それらを達成するために。最後に、セクション 5.4 とセクション 5.5 では、ネットワーク レベルの脅威について説明します。 ネットワークフラッディングとシビルそれぞれに対するそのようなポリシーとそれに対処する手段 攻撃します。 5.1 最前線の問題 FSS の目標と設計を説明するために、フロントランニングの 2 つの一般的な形式について説明します。 攻撃と既存のソリューションの制限。 フロントランニングはクラスを体現する トランザクション順序付け攻撃の割合: バックランニングやサンドイッチング (フロントランニングとバックランニング) [237] など、ここでは取り上げていない関連攻撃が多数あります。 ここでは、FSS も解決に役立ちます。 5.1.1 オラクルのフロントランニング blockchain アプリケーションにオフチェーン データを提供するという従来の役割では、oracles 前線攻撃の自然なターゲットになります。oracle を使用してさまざまな価格フィードを提供する一般的な設計パターンを検討してください。 オンチェーン取引所へ: oracle は定期的に (たとえば 1 時間ごとに) 価格データを収集します。 異なる資産を取得し、これらを交換契約に送信します。これらの価格データ取引 明らかな裁定取引の機会が存在します: たとえば、最新の oracle レポートのリストに 一部の資産の価格がはるかに高い場合、攻撃者は oracle レポートを前倒しで実行する可能性があります。 資産を買い占め、oracle の報告が処理されたらすぐに転売してください。 スピードバンプと遡及価格設定: oracle の最前線の問題に対する自然な解決策は、oracle レポートに他のトランザクションよりも特別な優先順位を与えることです。のために たとえば、oracle レポートは、マイナーに処理を奨励するために高額な料金で送信される可能性があります。 まずは彼らから。しかし、裁定取引の機会が高い場合、これはフロントランニングを妨げるものではありません。 また、マイナー自身による裁定取引を防ぐこともできません。 そのため、一部の取引所は、ユーザーのトランザクションを処理する前にいくつかのブロックのキューに入れるなど、より強力な「スピードバンプ」の実装に頼っています。 または、新しい oracle レポートが到着したときに価格を遡及的に調整します。これらのソリューションの欠点は、交換の実装が複雑になることです。 ストレージ要件が増加し、その結果、トランザクションコストが増加し、資産の交換がかなりの期間を経た後にのみ確認されるため、ユーザーエクスペリエンスが混乱します。 便乗: FSS に進む前に、ピギーバックについて説明します。 oracle の最前線の問題に対する洗練された解決策。住所には適用されません ただし、他のシナリオでは最前線で実行されます。 つまり、オンチェーン コントラクトに定期的にレポートを送信する代わりに、oracles ユーザーが売買時に取引に追加する署名付きレポートを公開する オンチェーン資産。その後、交換はレポートが有効で新しいことを確認するだけです (例: oracle は、レポートが有効なブロックの範囲に署名できます)、および抽出 そこからの関連する価格フィード。 このシンプルなアプローチには、上記の「スピードバンプ」に比べて多くの利点があります。 アプローチ: (1) 取引所契約は価格フィードの状態を保持する必要はありません。 取引コストの削減につながります。 (2) oracle レポートは必要に応じてチェーンに投稿されるため、oracle はより頻繁な更新 (例: 1 分ごと) を生成できます。 レポートのフロントランニングによる裁定取引の機会を最小限に抑える9。 (3) トランザクションは次のとおりです。 常に最新の価格フィードが含まれるため、すぐに検証できます。 ただし、このアプローチは完璧ではありません。まず、この便乗ソリューションでは、 取引所のユーザーには、最新の oracle レポートを取得してレポートに添付する義務があります。 取引。第二に、相乗りは裁定取引の機会を最小限に抑えることはできますが、 オンチェーンコントラクトの有効性に影響を与えることなく、それらを完全に防止します。確かに、もし oracle レポートはブロック番号 n まで有効で、その後トランザクションがブロックに送信されます。 n + 1 には、新しい有効なレポートが必要になります。伝播に固有の遅延があるため、 oracles からユーザーにレポートを送信すると、ブロック n + 1 に対して有効な新しいレポートは次のようになります。 9 裁定取引は、利用可能な資産価格の差が無関係な価格差を超える場合にのみ価値がある。 資産の売買に必要な手数料（採掘者や取引所が徴収するものなど）。ブロック n + 1 がマイニングされる前に、たとえばブロック n −k で公開されるため、 短期間のアービトラージの機会が存在する k ブロックのシーケンスを作成します。私たち 次に、FSS がこれらの制限をどのように回避するかを説明します。 FSS を使用した oracle レポートの優先順位付け: FSS は oracle の最前線の問題に対処できます 上記の相乗りソリューションに基づいて問題を解決しますが、追加のソリューションをプッシュします。 oracle レポートを使用してトランザクションを強化する作業は、分散型 Oracle ネットワークに報告されます。 高いレベルでは、oracle ノードはオンチェーン交換に向けたトランザクションを収集します。 リアルタイムの価格フィードに同意し、収集されたトランザクションとともに価格フィードをメインチェーン コントラクトにポストします。概念的には、このアプローチは次のように考えることができます。 「データ拡張トランザクション バッチ処理」。oracle により、 価格フィードは常にトランザクションに追加されます。 FSS ソリューションは、取引所のユーザーに対して透過的に実装できます。 セクション 5.2 で詳しく説明するように、契約ロジックへの変更は最小限に抑えられます。確保する 新しい oracle レポートがユーザー トランザクションよりも常に優先されることは、ほんの一例にすぎません FSS が採用および強制できる順序付けポリシー。金監院の秩序確保方針 公平性については、セクション 5.3 でより一般的に説明されています。 5.1.2 フロントランニング ユーザー トランザクション ここで、上記の防御方法が適用される一般的なアプリケーションでのフロントランニングに移ります。 機能しません。この問題は、次のシナリオを通じて幅広く捉えることができます。 攻撃者は、P2P ネットワークに送信されたユーザー トランザクション tx1 を確認し、 独自の敵対的なトランザクション tx2 を使用して、tx2 が tx1 よりも前に処理されるようにします（たとえば、支払いによって） 取引手数料が高くなります）。たとえば、この種の先走りは、 DeFi システム [90] の裁定取引の機会を悪用し、次のユーザーに影響を与えたボット さまざまな分散アプリケーション [101]。取引間に公正な秩序を課す blockchain で処理されると、この問題が解決されます。 もっと基本的には、tx1 の詳細を確認する必要すらない場合もあります。 その単なる存在を知っているだけで、敵対者はその存在を介して tx1 をフロントランできる可能性があります。 tx2 を所有し、tx1 を作成した無実のユーザーを騙します。たとえば、ユーザーは次のようにします。 定期的に特定の資産を取引することが知られています。このような攻撃を防ぐには、次のことが必要です メタデータの漏洩も回避する緩和策 [62]。この問題に対するいくつかの解決策 存在しますが、遅延やユーザビリティ上の懸念が生じます。 ネットワーク注文から FSS による確定注文まで: 前線で活躍する機会 既存のシステムには、順序を保証するメカニズムがないために発生します。 トランザクションはイベントの順序と情報の流れを尊重してチェーン上に表示されます ネットワークの外側。これは、blockchain 上のアプリケーション (取引プラットフォームなど) の実装の不備から生じる問題を表しています。理想的には、 blockchain でトランザクションが以前と同じ順序でコミットされていることを確認します。 作成され、blockchain の P2P ネットワークに送信されます。しかし、blockchain ネットワーク以来

Fair Sequencing Services general schematic showing transaction flow from users through DON to main chain

が分散されている場合、そのような順序は捕捉できません。したがって、FSS はメカニズムを導入します 分散されたことによってのみ生じる公平性の侵害を防ぐため blockchain ネットワークの性質。 5.2 FSSの詳細 図 12: 2 つの異なるトランザクション パスを持つ順序公平なメモリプール: 直接的かつ mempool ベース。 図 12 は、FSS の一般的な概略図を示しています。公平性を確保するために、FSS を提供する DON は、トランザクションが MAINCHAIN に入るときにトランザクションのフローを妨害する必要があります。 クライアント、MAINCHAIN 上の smart contract、またはその両方の調整が必要になる場合があります。高レベルでは、FSS によるトランザクションの処理は 3 つに分解できます。 以下に説明するフェーズ: (1) トランザクション監視。 (2) トランザクションの順序付け。そして (3) トランザクションの転記。トランザクションの順序付けに使用される順序付け方法に応じて、次のセクションで説明するように、追加のプロトコル手順が必要になります。 5.2.1 トランザクション処理 トランザクション監視: FSS が監視するには 2 つの異なるアプローチを想定しています。 特定の smart contract を宛先とするユーザー トランザクション (直接およびメモリプール ベース): • 直接: 直接アプローチは概念的には最も単純ですが、変更が必要です。 ユーザークライアントにより、トランザクションが分散型 Oracle に直接送信されるようになります。メインチェーンのノードではなく、ネットワークノード。 DON は収集します 特定の smart contract SC 宛てのユーザー トランザクションとそれらに基づく注文 いくつかの注文ポリシーに基づいて。 DON は、注文されたトランザクションを メインチェーン上のsmart contract。一部の注文メカニズムでは、トランザクションを作成するユーザーが暗号化する必要があるため、直接的なアプローチも必要となります。 FSS に送信する前に保護してください。 • Mempool ベース: FSS とレガシー クライアントの統合を容易にするために、DON Mempool Services (MS) を使用してメインチェーンの mempool を監視し、収集することができます。 取引。 多くの契約では直接送信が推奨される実装となる可能性が高く、 そして多くの場合、それはかなり実用的であるはずだと私たちは信じています。 既存の DApps を最小限の変更でサポートできる方法について簡単に説明します。 優れたユーザーエクスペリエンスを維持しながら直接送信します。アプローチについて説明します Ethereum と MetaMask [6] は現在最も人気のある選択肢であるため、使用しますが、 前述のテクニックは他のチェーンやウォレットにも拡張されるべきです。最近のEthereum 改善提案、「EIP-3085: ウォレット追加 Ethereum チェーン RPC メソッド」 [100]、 カスタム Ethereum チェーンを簡単にターゲットにできるようになります (異なる CHAIN ID を使用) MetaMask やその他のブラウザベースのウォレットからのリプレイ攻撃を防ぐための MAINCHAIN のセキュリティです。この提案の実装後、DApp は DON の使用を希望します。 フロントエンドに単一のメソッド呼び出しを追加するだけで、直接送信できるようになります。 Ethereum 互換 API を公開する DON へのトランザクション。その間、 「EIP-712: Ethereum 型付き構造化データ hash の作成と署名」 [49] は、わずかに より複雑ではあるが、すでに広く導入されている代替案であり、DApp ユーザーが使用できる DON トランザクションを指定して構造化データに署名するメタマスク。 DApp が送信できるのは、 この署名された構造化データは DON に送信されます。 最後に、ハイブリッドアプローチも可能であることに注意してください。 たとえば、レガシー クライアントはメイン チェーンのメモリプールにトランザクションを送信し続けることができますが、これは重要です トランザクション (oracle レポートなど) は DON ノード (特に、 価格フィードの更新などの oracle レポートを提供するノードのセットとノードのセット ただし、FSS が重複するか同一である可能性があります)。 トランザクションの順序付け: FSS の主な目的は、ユーザーのトランザクションが事前定義されたポリシーに従って順序付けされることを保証することです。このポリシーの性質上、 アプリケーションのニーズと、アプリケーションが要求する不当なトランザクション命令の種類によって異なります。 を防ぐことを目的としています。 DON の FSS はデータを処理し、ローカル状態を維持できるため、 彼らは、以下の情報に基づいて任意の順序付けポリシーを課す可能性があります。 oracles で入手できます。 特定の順序付けポリシーとその実装については、セクション 5.3 で後述します。トランザクション転記: ユーザーから直接受信した、またはメモリプールから収集されたユーザー トランザクションを収集して順序付けした後、DON はこれらのトランザクションをメイン チェーンに送信します。そのため、DON とメインチェーンの相互作用は残ります。 メインチェーンのマイナーによって管理される（不公平な可能性がある）トランザクション順序の影響を受けます。分散型トランザクション注文の利点を活用するには、ターゲットをスマートにします。 したがって、契約 SC は、DON を「一級」国民として扱うように設計されなければなりません。私たち 2 つのアプローチを区別します。 • DON のみのコントラクト: 最も単純な設計オプションは、メイン チェーンをスマートにすることです。 契約 SC は、DON によって処理されたトランザクションのみを受け入れます。これ smart contract が、提案された順序でトランザクションを処理することを保証します。 DON ですが、事実上、smart contract は委員会ベースのシステムで運営されるように制限されています (つまり、DON 委員会は現在、 トランザクションの注文と包含）。 • デュアルクラス コントラクト: メイン チェーンがスマートになる、より粒度の高い設計が推奨されます。 コントラクト SC は、DON とレガシーの両方から発生するトランザクションを受け入れます ただし、DON によって処理されなかったトランザクションには従来の「スピード バンプ」が発生します。たとえば、DON からのトランザクションが処理される可能性があります。 従来のトランザクションは smart contract によってすぐに「バッファリング」されます。 一定の期間。フロントランニングを防止するためのその他の標準メカニズム commit-reveal スキームや VDF [53] などはレガシーにも適用できます 取引。これにより、DON で注文されたトランザクションが確実に処理されます。 DON に望ましくない検閲権限を与えることなく合意された命令 取引。 FSS によるトランザクション順序付けの強制では、トランザクションが「オフチェーン」で集約される必要があるため、このソリューションは、オンチェーン処理コストの削減を目的とした他の集約手法と自然に組み合わされます。たとえば、収集した後、 トランザクションを注文すると、DON はこれらのトランザクションをメイン チェーンに送信する可能性があります。 単一の「バッチトランザクション」(例: rollup) により、トランザクションの総量が削減されます。 料金。 トランザクション順序の強制: DON 専用設計でもデュアルクラス設計でも、 DON のトランザクション順序が維持されることを保証するには、メイン チェーン smart contract SC と DON を共同設計する必要があります。ここでも、さまざまな状況を想定しています デザインオプション: • シーケンス番号: DON は各トランザクションにシーケンス番号を追加し、これらのトランザクションをメイン チェーンのメモリプールに送信できます。 メイン 10DON のトランザクション監視がメモリプールに基づいている場合、レガシー トランザクションは、DON によって収集されないように、DON トランザクションと区別できる必要があります (特別なタグなどを介して)。 トランザクションに埋め込むか、特定のガス価格を指定することによって、例えばDON トランザクションにはガスが発生しています 一定のしきい値を下回る価格。チェーン smart contract SC は、「順序を外して」到着したトランザクションを無視します。私たち この設定では、メインチェーンのマイナーが DON を無視することを決定できることに注意してください。 トランザクションの順序付けが行われるため、トランザクションが失敗します。 SC が (高価な) 状態を維持することで、ある程度正しいトランザクション順序を強制することが可能です。 TCP が、欠落したパケットが見つかるまで、順序が乱れたパケットをバッファリングする方法と同様です。 受け取りました。 • トランザクション nonces: 多くの blockchain、特に Ethereum については、 上記のシーケンス番号付けアプローチでは、組み込みトランザクション nonces を利用して、 メインチェーン smart contract SC がトランザクションを順番に処理するように強制します。 ここで、DON ノードは、DON ノード間で共有されるキーで保護された単一のメインチェーン アカウントを通じてトランザクションをメインチェーンに送信します。アカウントの トランザクション nonce は、トランザクションが正しい順序でマイニングおよび処理されることを保証します。 • トランザクションの集約: DON は、複数のトランザクションを rollup に集約できます。 (または rollup のようなバンドル内)。メインチェーン smart contract は次のようにする必要があります。 このような集約トランザクションを処理するように設計されています。 • メインチェーンプロキシによるトランザクションの集約: ここで、DON は同様にトランザクションをメインチェーンの 1 つの「メタトランザクション」にバンドルしますが、 カスタム プロキシ smart contract を使用してトランザクションを解凍し、 ターゲット契約SC。この手法はレガシー互換性に役立ちます。メタトランザクションは rollup と同様に動作しますが、非圧縮トランザクションで構成される点が異なります。 メインチェーンに一度ポストされたトランザクションのリスト。 最後の設計には、ユーザー トランザクションをシームレスにサポートするという利点があります。 DON のターゲットに到達する前に、メイン チェーン コントラクトを通じて自身がプロキシされます SCと契約。たとえば、あるウォレットにトランザクションを送信するユーザーを考えてみましょう。 コントラクトは内部トランザクションを SC に送信します。シーケンスの割り当て ユーザーのウォレット契約が正しくない限り、そのようなトランザクションに番号を付けるのは難しいでしょう。 すべての内部トランザクションでシーケンス番号を転送するように特別に設計されています。 SC。 同様に、そのような内部トランザクションを、SC に直接送信されるメタトランザクションに簡単に集約することはできません。さらなる設計上の考慮事項について説明します。 かかる代理取引は以下の通りです。 5.2.2 トランザクションの原子性 これまでの議論は、トランザクションが単一のオブジェクトと相互作用することを暗黙に想定してきました。 オンチェーン smart contract (例: ユーザーが取引所に購入リクエストを送信する)。それでも、 Ethereum などのシステムでは、単一のトランザクションが複数の内部トランザクションで構成される場合があります (たとえば、1 つの smart contract が別のコントラクト内の関数を呼び出すなど)。以下、私たちは、 「マルチコントラクト」トランザクションをシーケンスするための 2 つの高レベルの戦略について説明します。 トランザクションのアトミック性（つまり、トランザクションによって規定された一連のアクション）を維持する トランザクションはすべて正しい順序で実行されるか、まったく実行されません)。強力な原子性: 最も簡単な解決策は、上で説明したように、FSS を「複数契約」トランザクション全体に直接適用することです。つまり、ユーザーはトランザクションを送信します をネットワークに接続し、FSS がこれらのトランザクションを監視、シーケンスし、 メインチェーン。 このアプローチは技術的には簡単ですが、潜在的な制限が 1 つあります。 トランザクションは、公平性を活用することを希望する 2 つの契約 SC1 および SC2 と対話します。 シーケンス サービスの場合、これら 2 つの契約のシーケンス ポリシーは一貫している必要があります。つまり、それぞれが対話する 2 つの異なるトランザクション tx1 と tx2 があるとします。 SC1 と SC2 の両方で、SC1 のポリシーが tx2 よりも先に tx1 を順序付ける場合であってはなりません。 一方、SC2 のポリシーは逆の順序を規定しています。 対象となるシナリオの大部分では、さまざまな契約で採用される順序ポリシーが一貫していると想定されます。たとえば、SC1 と SC2 の両方 トランザクションを mempool へのおおよその到着時間によって順序付けしたい場合があります。 さらに、SC1 は、特定の oracle レポートが常に最初に配信されることを望む場合があります。として 後者の oracle レポート トランザクションは SC2 と対話せず、ポリシーは一貫しています。 弱い原子性: 完全に一般的に言えば、FSS は個人レベルで適用できます。 内部取引。 いくつかの初期値で構成される tx = { ˜txpre, ˜txSC, ˜txpost} という形式のトランザクションを考えてみましょう。 トランザクション 〜txpre。これにより、SC への内部トランザクション 〜txSC が発生します。 内部トランザクション ~txpost を発行します。 SC のシーケンス ポリシーによって、その方法が決定される場合があります。 内部トランザクション ~txSC は、送信される他のトランザクションに関して順序付けする必要があります ただし、~txpre と ~txpost のシーケンス順序はオープンのままにしておきます。 Ethereum などのシステムにおけるトランザクション処理の本質を考慮すると、特定の内部トランザクションを対象としたシーケンス サービスの開発は簡単ではありません。特別に設計されたコントラクト SC を使用すると、これは次のように実現可能です。 1. トランザクション TX がネットワークに送信され、(順序付けなしで) マイニングされます。 FSSによって実行されます）。最初の ˜txpre が実行され、 ˜txSC が呼び出されます。 2. SC は ~txSC を実行せずにリターンします。 3. FSS は SC への内部トランザクションを監視し、順序付けしてポストバックします。 ＳＣに送信する（すなわち、トランザクション〜ｔｘＳＣをＳＣに直接送信することによって）。 4. SCは、FSSから受信したトランザクション~txSCを処理し、~txSCから結果として生じる内部トランザクション~txpostを発行します。 このアプローチでは、トランザクションは完全にアトミックに実行されません（つまり、元の トランザクション TX は複数のオンチェーン トランザクションに分割されます)、ただし順序は 内部トランザクションは保存されます。 このソリューションには、多くの設計上の制約が伴います。たとえば、 ˜txpre は次のことはできません。 〜txSCと〜txpostが実行されると仮定します。さらに、SC は次のように設計する必要があります。 特定のユーザーに代わってトランザクション 〜txSC および 〜txpost を実行します。FSSから送られてきました。これらの理由により、より粗粒度の「強力なアトミック性」ソリューションが使用されます。 実際には上記の方が望ましいと思われます。 複数のトランザクションや それぞれの内部トランザクションには、FSS のトランザクション スケジューラに含まれる可能性があります。 リレーショナルのトランザクション マネージャーにあるものに似た複雑な関数 データベースマネージャー。 5.3 公正なトランザクションの順序付け ここでは、トランザクションの順序付けの公平性に関する 2 つの概念と、FSS によって実現される対応する実装について説明します。 ポリシーに基づく注文の公平性 FSS と安全な因果関係の保存によって課されるため、FSS での追加の暗号化手法が必要になります。 注文の公平性: 順序の公平性は、コンセンサスプロトコルにおける時間的な公平性の概念です これは Kelkar らによって初めて正式に導入されました。 [144]。 ケルカーら。取引が行われる自然な政策の形を達成することを目指します。 DON (または P2P ネットワーク、 メモリプールベースの FSS の場合)。ただし、分散型システムでは異なります。 ノードではトランザクションが異なる順序で到着する可能性があります。 トータルオーダーの確立 すべてのトランザクションに関する問題は、基礎となるコンセンサス プロトコルによって解決されます。 メインチェーン。 ケルカーら。 [144] したがって、次のような弱い概念を導入します。 これは、「ブロック順序の公平性」と呼ばれる分散型 Oracle ネットワークの助けを借りて実現されます。 DON が一定期間中に受信したトランザクションをグループ化します。 「block」を選択し、ブロックのすべてのトランザクションを同時に同じ位置に挿入します。 (つまり、高さ) を MAINCHAIN に追加します。したがって、それらは一緒に注文され、実行可能でなければなりません それらの間に矛盾を生じさせることなく、並行して実行します。 大まかに言うと、orderfairness は、ノードの大部分が τ2 より前にトランザクション τ1 を見た場合、次のように述べます。 τ1 は、τ2 より前または同じブロック内でシーケンスされます。そんな粗雑なことを課すことで、 トランザクション注文の粒度が向上するため、フロントランニング攻撃やその他の注文関連の攻撃の機会が大幅に減少します。 ケルカーら。 Aequitas [144] と呼ばれるプロトコル ファミリを提案します。 同期、部分同期、非同期ネットワーク設定など、さまざまな導入モデルに対応します。 Aequitas プロトコルは、基本的な BFT コンセンサスに比べて通信オーバーヘッドが大きいため、実用には理想的ではありません。 しかし、私たちは、使用できる Aequitas の実用的な亜種が出現すると信じています。 FSS およびその他のアプリケーションのトランザクション シーケンス用。いくつかの関連スキームには、 付随する形式主義が少なく、特性が弱いものはすでに提案されていますが、 例: [36、151、236] ですが、実際のパフォーマンスはより優れています。これらのスキームをサポートできます FSSでも。 「公平性」という用語が blockchain の他の場所に登場していることにも注目してください。 異なる意味を持つ文学、すなわち、機会という意味での公平性コミットされたリソース [106, 181] または validator 秒に比例するマイナー 機会均等 [153]。 安全な因果関係の保存: 分散プラットフォームにおけるフロントランニングやその他の順序違反を防ぐ最も広く知られているアプローチは、暗号化に依存しています。 テクニック。それらの共通の特徴は、トランザクション データ自体を非表示にし、次の処理が完了するまで待機することです。 コンセンサス層での順序が確立され、トランザクションデータが明らかになります 後で処理します。これにより、トランザクション間の因果関係が維持されます。 blockchain によって実行されます。関連するセキュリティ概念と暗号化プロトコル blockchain の出現よりかなり前に開発されました [71、190]。 「入力因果関係」[190] および「安全な因果関係保存」[71、97] のセキュリティ条件では、トランザクションに関する情報が一切知られないようにすることが形式的に要求されます。 グローバルな順序におけるこのトランザクションの位置が決定される前。敵対者は、暗号化された方法で、その時点までいかなる情報も推測できてはなりません。 強いセンス。 因果関係を維持するための 4 つの暗号化手法を区別できます。 • Commit-Reveal プロトコル [29、142、145]: トランザクションがアナウンスされる代わりに 平文では、トランザクションに対する暗号化されたコミットメントのみがブロードキャストされます。コミット済みだが非表示のトランザクションがすべて注文された後 (blockchain の初めに) MAINCHAIN 自体のシステム、ただしここでは FSS による）、送信者はコミットメントをオープンし、所定の時間間隔内にトランザクション データを明らかにする必要があります。 次にネットワークは、開口部が以前の約束を満たしていることを検証します。の このメソッドの起源は、blockchains の出現より前に遡ります。 このアプローチは特に単純ですが、かなりの欠点があり、2 つの理由から採用が簡単ではありません。まず、注文プロトコルのレベルではコミットメントのみが存在するため、トランザクションのセマンティクスは コンセンサス中に検証することはできません。クライアントとの追加の往復 が必要です。しかし、より厳しいのは、開口部がなくなる可能性である。 これはサービス妨害攻撃に相当する可能性があります。さらに、それは 一貫性のある分散型環境では、開口部が有効であるかどうかを判断するのは困難です。 すべての参加者がオープニングが到着したかどうかに同意する必要があるため、この方法で 時間。 • リカバリが遅延するコミット-リビールプロトコル [145]: に関する 1 つの課題 commit-reveal アプローチでは、クライアントは投機的にトランザクションにコミットし、後続のトランザクションによって収益が得られる場合にのみ、後でそれを公開することができます。あ commit-reveal アプローチの最近の変形により、これに対する回復力が向上します。 一種の不正行為。特に、TEX プロトコル [145] はこの問題に対処します。 暗号化されたトランザクションに復号キーが含まれる賢いアプローチを使用する 検証可能な遅延関数 (VDF) [53、221] を計算することで取得できます。クライアントの場合 トランザクションを適時に復号化できなかった場合、システム内の他のユーザーが復号化します。 彼女に代わって、適度に難しい暗号パズルを解くことでそれを解決します。• しきい値暗号化 [71、190]: この方法は、DON が実行する可能性があることを利用します。 しきい値暗号化操作。 FSS が暗号化パブリックを維持していると仮定します。 キー pkO と oracle は、対応する秘密キーをそれらの間で共有します。 その後、クライアントは pkO でトランザクションを暗号化し、FSS に送信します。 FSS命令 DON 上のトランザクションを解析し、それらを復号化して、最後にそれらを 固定順序での MAINCHAIN。したがって、暗号化により注文が確実に行われます。 トランザクションの内容に基づくのではなく、データ自体がいつでも利用可能であることを示します。 必要です。 この方法はもともと Reiter と Birman [190] によって提案され、後に Cachin らによって改良されました。 [71]、許可されたコンセンサスと統合されました プロトコル。より最近の研究では、しきい値暗号化の使用を検討しています。 一般的なメッセージ [33、97] および共有データ [41] を使用した一般的な計算のためのコンセンサス レベルのメカニズム。 commit-reveal プロトコルと比較して、しきい値暗号化は単純なサービス拒否攻撃を防止します (ただし、復号化の計算コストを考慮すると注意が必要です)。これにより、DON は自律的に、独自の速度で、何もせずに進むことができます。 さらなるクライアントのアクションを待っています。トランザクションは、復号化された後すぐに検証できます。さらに、クライアントはすべてのトランザクションを 1 つの暗号化キーで暗号化します。 DON のキーと通信パターンは他のものと同じままです 取引。しきい値キーを安全に管理し、ノードを変更する ただし、O はさらなる問題を引き起こす可能性があります。 • コミットされた秘密の共有 [97]: トランザクション データを暗号化する代わりに、 DON が保持するキーの場合、クライアントはそれを O のノードに対して秘密共有することもできます。 ハイブリッドで計算上安全な秘密共有スキームを使用すると、トランザクションは まず、ランダムなキーを使用した対称暗号を使用して暗号化されます。対応する対称キーのみが共有され、暗号文は DON に送信されます。 クライアントは、個別に暗号化されたメッセージを使用して、O の各ノードに 1 つのキー共有を送信する必要があります。残りのプロトコル手順はしきい値の場合と同じです ただし、トランザクション データは対称暗号化で復号化されます。 共有からトランザクションごとのキーを再構築した後のアルゴリズム。 この方法では、公開鍵暗号システムの設定や管理が不要です。 DON に関連付けられています。ただし、クライアントは次のノードを認識している必要があります。 O それぞれと安全なコンテキストで通信します。 クライアントのさらなる負担。 暗号化方式は情報に対する完全な保護を提供しますが、 送信されたトランザクションからネットワークに漏洩するため、メタデータは隠蔽されません。のために たとえば、送信者の IP アドレスまたは Ethereum アドレスは引き続き使用される可能性があります。 フロントランニングやその他の攻撃を実行する敵。さまざまなプライバシー強化 ネットワーク層 ([52、95、107] など) またはトランザクション層に導入された技術、 この目標を達成するには、たとえば [13, 65] が必要になります。特定の作品の影響 メタデータの内容、つまりトランザクションがどのコントラクトに送信されるかを（部分的に）隠すことができます同じ DON 上で多くのコントラクトを多重化することによって。暗号の隠蔽 トランザクション自体も、破損したトランザクションによるトランザクションの優先順位付けを妨げるものではありません。 DON ノードがトランザクション送信者と共謀しています。 暗号プロトコルによって保証される安全な因果関係は、あらゆるポリシーの順序の公平性の保証を補完するものであり、私たちはこの 2 つの組み合わせを検討するつもりです。 可能な場合はメソッドを使用します。敵対者が重大な利益を得ることができない場合、 メタデータを観察すると、安全な因果関係保存プロトコルを併用できます。 素朴な注文アプローチも同様です。たとえば、oracle ノードはトランザクションを書き込むことができます 重複することなく、受け取ったらすぐに L に送信します。トランザクションは次のようになります。 L 上の出現に従って順序付けされ、その後復号化されます。 また、公正な注文を強制する手段として TEE の使用を検討する予定です。のために たとえば、Tesseract [44] は因果的順序付けの形式を実現していると見なすことができますが、 TEE が明示的な形式でトランザクションを処理する能力によって強化されます。 秘密を保持します。 5.4 ネットワーク層の考慮事項 これまでのところ、FSS についての説明は主に、次のことを強制する問題に焦点を当ててきました。 最終的なトランザクションの順序は、ネットワーク内で観察された順序と一致します。以下、 ネットワーク層自体で発生する可能性のある公平性の問題を考慮します。 従来の電子市場の高頻度トレーダーは多額の投資を行っています [64] は優れたネットワーク速度を得るためにリソースを使用しており、暗号通貨取引所のトレーダーも同様の動作を示しています [90]。ネットワーク速度は、次の点で利点をもたらします。 他の当事者の取引を観察し、競合する取引を提出する。 実際に導入され、書籍『Flash Boys [155]』で普及した解決策の 1 つは次のとおりです。 最初に IEX 取引所 [128] で導入され、その後他の取引所でも導入された「スピード バンプ」 [179] を交換します (結果はさまざまです [19])。このメカニズムは、市場へのアクセスに遅延 (IEX では 350 マイクロ秒) を課し、市場における利点を中和することを目的としています。 スピード。経験的証拠、例: [128]、特定の取引を減らす効果を裏付ける 一般投資家にとってのコスト。 FSS は、単純に非対称を実装するために使用できます。 速度の上昇 - 受信トランザクションを遅らせるもの。 バディッシュ、クラムトン、シム [64] は、速度の利点を利用すると主張しています。 継続時間市場では避けられないものであり、市場における構造的救済策を主張しています。 バッチオークションベースの市場の形態。しかし、このアプローチは広く定着していない 既存の取引プラットフォームで。 従来の取引システムは集中化されており、通常は次の方法で取引を受け取ります。 単一のネットワーク接続。対照的に、分散型システムでは、次のことが可能です。 複数の有利な点からトランザクションの伝播を観察します。その結果、P2P ネットワークにおけるネットワーク フラッディングなどの動作を観察することが可能になります。 私たちは意図しています 開発者がポリシーを指定するのに役立つ FSS へのネットワーク層のアプローチを調査する このような望ましくないネットワーク動作を禁止します。5.5 エンティティレベルの公平性ポリシー 注文の公平性と安全な因果関係は、次のようなトランザクションに対して注文を強制することを目的としています。 作成され、最初にネットワークに送信された時刻が尊重されます。この公平性の概念の限界は、敵対者が行う攻撃を防ぐことができないことです。 システムに多くのトランザクションを溢れさせることで優位性を得るという戦略が観察されています token 売上 [159] において効果的なトランザクション スナイピングを実行する方法として広く普及しています。 混雑を引き起こし、債務担保ポジション (CDP) [48] の清算を引き起こします。 言い換えれば、注文の公平性は、プレイヤーではなくトランザクションに関する公平性を強制します。 CanDID システム [160] に示されているように、DECO などの oracle ツールを使用することが可能です または、Town Crier をノード委員会 (DON など) と連携して達成します。 プライバシーを保護しながら、さまざまな形のシビル耐性を実現します。ユーザーはアイデンティティを登録できます そして、身元自体を明らかにすることなく、その独自性の証拠を提供します。 シビル耐性のある認証情報は、トランザクションの順序付けを強化するための可能なアプローチを提供します フラッディング攻撃の機会を制限するような方法でポリシーを適用します。たとえば、 token 販売では、登録ユーザーごとに 1 つのトランザクションのみが許可される場合があります。 社会保障番号などの国民識別子の一意性の証明が必要です。 このようなアプローチは確実ではありませんが、トランザクション フラッディング攻撃を軽減するための有用なポリシーであることが証明される可能性があります。

Khung thực thi giao dịch DON

(DON-TEF) DONs sẽ cung cấp oracle và hỗ trợ tài nguyên phi tập trung cho các giải pháp lớp 2 trong cái mà chúng tôi gọi là Khung thực thi giao dịch mạng Oracle phi tập trung (DONTEF) hay gọi tắt là TEF. Ngày nay, tần suất cập nhật các hợp đồng DeFi bị giới hạn bởi độ trễ của chuỗi chính, ví dụ: khoảng thời gian chặn trung bình là 10-15 giây trong Ethereum [104]—cũng như chi phí của đẩy lượng lớn dữ liệu trên chuỗi và thông lượng tính toán/tx bị hạn chế— thúc đẩy các phương pháp mở rộng quy mô như sharding [148, 158, 232] và thực thi lớp 2 [5, 12, 121, 141, 169, 186, 187]. Kể cả blockchain có thời gian giao dịch nhanh hơn nhiều, ví dụ: [120], đã đề xuất các chiến lược mở rộng quy mô liên quan đến tính toán ngoài chuỗi [168]. TEF có nghĩa là hoạt động như một tài nguyên lớp 2 cho bất kỳ hệ thống lớp 1 / MAINCHAIN ​​nào như vậy. Sử dụng TEF, DONs có thể hỗ trợ cập nhật nhanh hơn trong hợp đồng MAINCHAIN trong khi giữ lại các đảm bảo tin cậy quan trọng được cung cấp bởi chuỗi chính. TEF có thể hỗ trợ bất kỳ kỹ thuật và mô hình thực thi lớp 2 nào, bao gồm rollups,11 lạc quan rollups, Validium, v.v., cũng như mô hình ngưỡng tin cậy trong đó DON các nút thực hiện giao dịch. TEF bổ sung cho FSS và nhằm hỗ trợ nó. Nói cách khác, bất kỳ ứng dụng chạy trong TEF có thể sử dụng FSS. 11Thường được gọi là “zk-rollups”, một cách gọi sai vì chúng không nhất thiết cần bằng chứng không có kiến ​​thức.

Transaction Execution Framework schematic showing mempool, clearing, and settlement flow

6.1 Tổng quan về TEF TEF là một mẫu thiết kế để xây dựng và thực hiện một hệ thống hybrid hiệu suất smart contract SC. Theo ý tưởng chính đằng sau smart contracts lai, TEF bao gồm một phân tách SC thành hai phần: (1) Cái mà chúng ta gọi trong ngữ cảnh TEF là mỏ neo hợp đồng SCa trên MAINCHAIN và logic (2) DON yêu cầu chúng tôi gọi là tệp thực thi TEF. Chúng ta sử dụng SC ở đây để biểu thị hợp đồng logic được thực hiện bằng sự kết hợp của SCa và mong đợi. (Như đã lưu ý ở trên, chúng tôi mong đợi phát triển các công cụ biên dịch để phân tách một tự động ký hợp đồng SC vào các thành phần này.) Phần thực thi TEF là công cụ xử lý các giao dịch của người dùng trong SC. Nó có thể thực thi một cách hiệu quả vì nó chạy trên DON. Nó có một số chức năng: • Nhập giao dịch: yêu cầu nhận hoặc tìm nạp giao dịch của người dùng. Nó có thể làm như vậy trực tiếp, tức là thông qua việc gửi giao dịch trên DON hoặc qua MAINCHAIN mempool bằng MS. • Thực hiện giao dịch nhanh: yêu cầu xử lý các giao dịch liên quan đến tài sản trong SC. Nó thực hiện điều đó cục bộ, tức là trên DON. • Truy cập bộ chuyển đổi / nhanh chóng và chi phí thấp oracle: exect có quyền truy cập riêng vào báo cáo oracle và dữ liệu bộ điều hợp khác dẫn đến nội dung, ví dụ: nhanh hơn, rẻ hơn và chính xác hơn định giá hơn so với việc thực hiện MAINCHAIN. Hơn nữa, quyền truy cập oracle ngoài chuỗi giảm chi phí vận hành của oracle, do đó chi phí sử dụng hệ thống, bằng cách tránh lưu trữ trên chuỗi đắt tiền. • Đồng bộ hóa: yêu cầu đẩy các bản cập nhật định kỳ từ DON lên MAINCHAIN, cập nhật SCa. Hợp đồng neo là giao diện người dùng MAINCHAIN ​​của SC. Là thành phần có độ tin cậy cao hơn của SC, nó phục vụ một số mục đích: • Giám sát tài sản: Tiền của người dùng được gửi vào, giữ và rút khỏi SCa. • Đồng bộ hóa xác minh: SCa có thể xác minh tính chính xác của các cập nhật trạng thái khi được kích hoạt đồng bộ hóa, ví dụ: SNARK được đính kèm với rollups. • Đường ray bảo vệ: SCa có thể bao gồm các điều khoản để bảo vệ chống tham nhũng hoặc hư hỏng mong đợi. (Xem Phần 7 để biết thêm chi tiết.) Trong TEF, tiền của người dùng được lưu giữ trên MAINCHAIN, nghĩa là DON bản thân nó không được giám sát. Tùy thuộc vào việc lựa chọn cơ chế đồng bộ hóa (xem bên dưới), người dùng có thể cần chỉ tin cậy DON để có báo cáo oracle chính xác và đồng bộ hóa kịp thời với MAINCHAIN. Mô hình tin cậy thu được rất giống với mô hình dành cho DEX dựa trên sổ đặt hàng, ví dụ: [2], mà ngày nay thường bao gồm một thành phần ngoài chuỗi để khớp lệnh và một thành phần trên chuỗi để thanh toán bù trừ.Để sử dụng từ vựng về hệ thống thanh toán, người ta có thể coi exect là thành phần của SC chịu trách nhiệm thanh toán bù trừ, trong khi SCa xử lý việc quyết toán. Xem Hình 13 để biết sơ đồ mô tả của TEF. Hình 13: Sơ đồ TEF. Trong ví dụ này, các giao dịch đi qua mempool của MAINCHAIN qua MS tới DON. Lợi ích của TEF: TEF mang lại ba lợi ích chính: • Hiệu suất cao: SC kế thừa thông lượng cao hơn nhiều của DON so với MAINCHAIN cho cả giao dịch và báo cáo oracle. Ngoài ra, exect có thể xử lý các giao dịch nhanh hơn và phản hồi các báo cáo oracle một cách kịp thời hơn so với việc chỉ triển khai trên MAINCHAIN. • Phí thấp hơn: Quá trình đồng bộ hóa ít nhạy cảm về thời gian hơn so với xử lý giao dịch và các giao dịch có thể được gửi từ DON tới MAINCHAIN ​​theo đợt. Do đó, phí trên mỗi giao dịch trên chuỗi (ví dụ: chi phí gas) với phương pháp này thấp hơn nhiều so với hợp đồng chỉ chạy trên MAINCHAIN. • Tính bảo mật: Cơ chế bảo mật của DON có thể được áp dụng chịu đựng SC.

Giới hạn của TEF: Một hạn chế của TEF là nó không hỗ trợ tức thời rút tiền, vì chúng chỉ xảy ra trên MAINCHAIN: Khi gửi yêu cầu rút tiền tới SCa, người dùng có thể phải chờ đợi để thực hiện cập nhật trạng thái bao gồm giao dịch rút tiền trước khi nó có thể được phê duyệt. Chúng tôi thảo luận về một số biện pháp khắc phục từng phần, tuy nhiên, trong Phần 6.2. Một hạn chế khác của TEF là nó không hỗ trợ thành phần nguyên tử DeFi hợp đồng trên MAINCHAIN, cụ thể là khả năng định tuyến tài sản qua nhiều DeFi hợp đồng trong một giao dịch duy nhất. Tuy nhiên, TEF có thể hỗ trợ tính nguyên tử như vậy giữa DeFi hợp đồng chạy trên cùng DON. Chúng tôi cũng thảo luận về một số cách để giải quyết vấn đề này vấn đề trong Phần 6.2. 6.2 Định tuyến giao dịch Giao dịch cho SC có thể được người dùng gửi trực tiếp tới DON hoặc có thể được chuyển qua mempool trong MAINCHAIN (thông qua FSS). Có bốn loại giao dịch riêng biệt, mỗi loại trong đó yêu cầu xử lý khác nhau: Giao dịch trong hợp đồng: Bởi vì nó tránh được sự phức tạp của động lực khí, TEF mang lại cho SC sự linh hoạt hơn trong việc xử lý các giao dịch so với trước đây. có sẵn trong hợp đồng lớp 1. Ví dụ: trong khi giao dịch mempool trong Ethereum có thể bị ghi đè bằng một giao dịch mới với giá gas cao hơn, SC có thể coi giao dịch hoạt động trên các tài sản trong SC là có thẩm quyền ngay khi nó hiển thị trong mempool. Do đó, SC không cần đợi giao dịch được xác nhận trong một khối, dẫn đến độ trễ giảm đáng kể. Ủy quyền: Người dùng có thể muốn gửi giao dịch τ tới SC thông qua hợp đồng ví hoặc hợp đồng khác trên MAINCHAIN. DON có thể mô phỏng việc thực thi τ trên MAINCHAIN để xác định xem liệu nó có dẫn đến giao dịch tiếp theo với SC hay không. Nếu vậy, τ có thể được sắp xếp theo trình tự với các giao dịch khác dành cho SC thực hiện. Có một vài khả năng về cách DON xác định các giao dịch đó: (1) DON có thể mô phỏng tất cả các giao dịch trong mempool (một cách tiếp cận tốn kém); (2) Một số hợp đồng hoặc các loại hợp đồng, ví dụ: ví, có thể được liệt kê để theo dõi bởi DON; hoặc (3) Người dùng có thể chú thích các giao dịch để kiểm tra DON. Vấn đề trở nên phức tạp hơn khi một giao dịch đơn lẻ tương tác với hai hợp đồng SC1 và SC2, cả hai đều sử dụng Dịch vụ sắp xếp thứ tự công bằng và có chính sách đặt hàng không tương thích. Ví dụ: DON có thể là chuỗi τ vào thời điểm gần nhất đó là tương thích với cả hai. Tiền gửi: Giao dịch gửi tài sản MAINCHAIN vào SC cần phải được xác nhận trong một khối trước khi SC có thể coi nó là hợp lệ. Khi nó phát hiện việc khai thác một giao dịch gửi tài sản (ví dụ: Ether) vào SCa, có thể xác nhận ngay lập tứctiền gửi. Ví dụ: nó có thể áp dụng giá được báo cáo oracle hiện tại trên DON cho tài sản. Rút tiền: Như đã lưu ý ở trên, hạn chế của TEF là việc rút tiền không phải lúc nào cũng được thực hiện ngay lập tức. Trong mô hình thực thi loại rollup, việc rút tiền yêu cầu phải được sắp xếp theo thứ tự với các giao dịch khác, tức là được cuộn lại, để được an toàn đã được xử lý. Tuy nhiên, có một số biện pháp khắc phục một phần hạn chế này. Nếu DON có thể nhanh chóng tính toán bằng chứng hợp lệ rollup cho giao dịch rút tiền thì việc quan sát giao dịch của người dùng τ trong mempool có thể gửi giao dịch cập nhật trạng thái τ ′ với giá gas cao hơn, một kiểu chạy trước có lợi. Với điều kiện là τ không được khai thác trước khi τ ′ đến mempool, τ ′ sẽ đứng trước τ và τ sẽ có hiệu lực đối với việc rút tiền đã được phê duyệt. Trong biến thể TEF trong đó DON được dựa vào để tính toán các cập nhật trạng thái (xem biến thể ký ngưỡng bên dưới), DON có thể xác định ngoài chuỗi liệu τ có nên được phê duyệt dựa trên trạng thái của SC khi thực thi nó hay không. DON sau đó có thể gửi một giao dịch τ ′ phê duyệt việc rút tiền τ—mà không ảnh hưởng đến toàn bộ giao dịch cập nhật trạng thái. Nếu cách tiếp cận này không thể thực hiện được hoặc trong trường hợp nó không thành công, thì DON đã bắt đầu giao dịch τ ′ có thể gửi tiền cho người dùng để phản hồi lại τ để người dùng không cần phải bắt đầu một giao dịch bổ sung. 6.3 Đang đồng bộ hóa Tệp thực thi TEF đẩy các bản cập nhật định kỳ từ DON lên MAINCHAIN, cập nhật trạng thái của SCa trong quy trình mà chúng tôi gọi là đồng bộ hóa. Đồng bộ hóa có thể được nghĩ đến như việc truyền bá các giao dịch lớp 2 sang lớp 1, do đó TEF có thể rút ra bất kỳ số nào kỹ thuật hiện có cho mục đích này, bao gồm rollups [5, 12, 16, 69], lạc quan rollups [10, 11, 141], Validium [201] hoặc ký ngưỡng cơ bản, ví dụ: BLS ngưỡng, Schnorr hoặc ECDSA [24, 54, 116, 202]. Về nguyên tắc, môi trường thực thi đáng tin cậy cũng có thể chứng thực tính đúng đắn của các thay đổi trạng thái, mang lại hiệu suất cao hơn nhiều thay thế cho rollups, nhưng với mô hình tin cậy phụ thuộc vào phần cứng. (Xem ví dụ: [80].) Dưới đây chúng tôi so sánh các tùy chọn đồng bộ hóa này với ba thuộc tính chính trong TEF: • Tính sẵn có của dữ liệu: Trạng thái của SC được lưu trữ ở đâu? Ít nhất ba lựa chọn là có sẵn dưới dạng TEF: trên MAINCHAIN, trên DON hoặc bởi một số bộ lưu trữ của bên thứ ba các nhà cung cấp như IPFS. Họ đạt được các đảm bảo an ninh, tính sẵn sàng khác nhau cấp độ và hồ sơ thực hiện. Tóm lại, việc lưu trữ trạng thái trên MAINCHAIN cho phép khả năng kiểm toán trực tuyến và loại bỏ sự phụ thuộc vào bất kỳ bên nào về tính khả dụng của trạng thái; mặt khác, việc lưu trữ trạng thái ngoài chuỗi có thể giảm chi phí lưu trữ và cải thiện thông lượng, với chi phí phải trả là tin tưởng nhà cung cấp dịch vụ lưu trữ (DON hoặc bên thứ ba) cho tính sẵn có của dữ liệu. Tất nhiên, các mô hình linh hoạt kết hợp các tùy chọn này cũng có thể. Chúng tôi chỉ ra dạng yêu cầu sẵn có của dữ liệu trong Bảng 1.• Đảm bảo tính chính xác: SCa xác định tính chính xác của các bản cập nhật bằng cách nào được thúc đẩy bởi sự mong đợi? Điều này ảnh hưởng đến tải tính toán trên exect và SCa và độ trễ đồng bộ hóa (xem bên dưới). • Độ trễ: Độ trễ đồng bộ hóa có ba yếu tố góp phần: (1) Thời gian thực hiện để mong đợi tạo giao dịch đồng bộ hóa τsync; (2) Thời gian cần thiết cho τsync được xác nhận trên MAINCHAIN; và (3) Thời gian để τsync phát huy tác dụng SCa. Trong TEF, độ trễ đặc biệt quan trọng đối với việc rút tiền (nhưng ít hơn đối với giao dịch trong hợp đồng) vì việc rút tiền nhất thiết phải có (ít nhất đồng bộ hóa trạng thái một phần). Đang đồng bộ hóa tùy chọn dữ liệu sẵn có Tính đúng đắn đảm bảo Độ trễ Tổng hợp [5, 12, 16, 69] Trên chuỗi Bằng chứng hiệu lực Thời gian thực hiện để tạo ra bằng chứng hợp lệ (ví dụ: số phút trong hệ thống hiện tại) Xác thực [201] Chuỗi Off Bằng chứng hiệu lực Tương tự như trên Lạc quan rollup [10, 11, 141] Trên chuỗi bằng chứng gian lận Độ dài của thử thách thời kỳ (ví dụ: ngày hoặc tuần) Ngưỡng ký [24, 54, 116, 202] Linh hoạt Ngưỡng chữ ký của DON tức thời Môi trường thực thi đáng tin cậy [80] Linh hoạt Dựa trên phần cứng chứng thực tức thời Bảng 1: Các tùy chọn đồng bộ hóa khác nhau trong TEF và các thuộc tính của chúng. Bảng 1 tóm tắt các thuộc tính này trong năm tùy chọn đồng bộ hóa chính trong TEF. (Lưu ý rằng chúng tôi không có ý định so sánh các công nghệ này như việc mở rộng quy mô lớp 2 độc lập giải pháp. Vì lý do đó, chúng tôi giới thiệu người đọc đến ví dụ: [121].) Bây giờ chúng ta thảo luận về từng tùy chọn đồng bộ hóa. Bản tổng hợp: rollup [69] là một giao thức trong đó quá trình chuyển đổi trạng thái được thực hiện bởi một lô giao dịch được tính toán ngoài chuỗi. Sự thay đổi trạng thái sau đó được lan truyền lên MAINCHAIN. Để triển khai rollups, neo smart contract SCa lưu trữ trạng thái đại diện thu gọn Rstate (ví dụ: gốc Merkle) của trạng thái thực tế. Để đồng bộ, exect gửi τsync = (T, R' state) tới SCa trong đó T là tập hợp các giao dịch được xử lý kể từ lần cuối cùngđồng bộ và R′ trạng thái là biểu diễn thu gọn của trạng thái mới được tính bằng cách áp dụng các giao dịch trong T sang trạng thái R trước đó. Có hai biến thể phổ biến khác nhau về cách SCa xác minh cập nhật trạng thái trong τsync. Đầu tiên, (zk-)rollups, đính kèm một lập luận ngắn gọn về tính đúng đắn, đôi khi được gọi là một bằng chứng hợp lệ cho quá trình chuyển đổi Rstate →R′ trạng thái. Để triển khai biến thể này, hãy mong đợi tính toán và gửi bằng chứng hợp lệ (ví dụ: bằng chứng zk-SNARK) cùng với τsync, chứng minh rằng R’ state là kết quả của việc áp dụng T vào trạng thái hiện tại của SCa. mỏ neo hợp đồng chỉ chấp nhận cập nhật trạng thái sau khi nó đã xác minh bằng chứng. Những rollup lạc quan không bao gồm những lập luận về tính đúng đắn nhưng có staking và thách thức các thủ tục tạo điều kiện thuận lợi cho việc xác minh phân tán các chuyển đổi trạng thái. Vì điều này rollup biến thể, SCa tạm chấp nhận τsync giả sử nó đúng (do đó mang lại sự lạc quan) nhưng τsync không có hiệu lực cho đến sau thời gian thử thách, trong thời gian đó bất kỳ bên nào giám sát MAINCHAIN có thể xác định các cập nhật trạng thái sai sót và thông báo cho SCa để thực hiện các hành động cần thiết (ví dụ: khôi phục trạng thái và đưa ra một hình phạt theo yêu cầu.) Cả hai biến thể rollup đều đạt được tính khả dụng của dữ liệu trên chuỗi khi các giao dịch được đăng trên chuỗi, từ đó trạng thái đầy đủ có thể được xây dựng. Độ trễ của zk-rollups là bị chi phối bởi thời gian cần thiết để tạo ra các bằng chứng hợp lệ, thường là về thứ tự phút trong các hệ thống hiện có [16] và có thể sẽ thấy sự cải thiện theo thời gian. Mặt khác, rollup lạc quan có độ trễ cao hơn (ví dụ: ngày hoặc tuần) bởi vì thời gian thử thách cần phải đủ dài để các bằng chứng gian lận có thể phát huy tác dụng. các hàm ý của việc xác nhận chậm là tinh tế và đôi khi cụ thể đối với sơ đồ, do đó một phân tích kỹ lưỡng là nằm ngoài phạm vi. Ví dụ: một số chương trình nhất định coi việc thanh toán giao dịch là "cuối cùng không cần sự tin cậy" [109] trước khi cập nhật trạng thái được xác nhận, vì một người dùng thông thường có thể xác minh rollup nhanh hơn nhiều so với MAINCHAIN. Xác thực: Validium là một dạng (zk-)rollup chỉ cung cấp dữ liệu ngoài chuỗi và không duy trì tất cả dữ liệu trên MAINCHAIN. Cụ thể, exect chỉ gửi cái mới nêu và bằng chứng nhưng không giao dịch với SCa. Với đồng bộ hóa kiểu Validium, ngoại trừ và DON thực thi nó là các bên duy nhất lưu trữ trạng thái hoàn chỉnh và thực hiện các giao dịch. Giống như zk-rollups, độ trễ đồng bộ hóa bị chi phối bởi tính hợp lệ thời gian tạo bằng chứng. Tuy nhiên, không giống như zk-rollups, đồng bộ hóa kiểu Validium làm giảm chi phí lưu trữ và tăng thông lượng. Ngưỡng ký bởi DON: Giả sử ngưỡng DON nút là trung thực, tùy chọn đồng bộ hóa đơn giản và nhanh chóng là có các nút DON ký tên chung vào trạng thái mới. Cách tiếp cận này có thể hỗ trợ cả tính khả dụng của dữ liệu trên chuỗi và ngoài chuỗi. Lưu ý rằng nếu người dùng tin cậy DON cho oracle cập nhật, họ không cần phải tin cậy hơn nữa để chấp nhận cập nhật trạng thái, vì chúng đã ở trong mô hình ngưỡng tin cậy. Một lợi ích khác của ngưỡng ký là độ trễ thấp. Hỗ trợ các định dạng chữ ký giao dịch mới như được đề xuất trong EIP-2938 [70] và được gọi là trừu tượng hóa tài khoản sẽ tạo ra ngưỡng việc ký kết dễ thực hiện hơn nhiều vì nó sẽ loại bỏ sự cần thiết của ngưỡng ECDSA, bao gồm các giao thức phức tạp hơn đáng kể (ví dụ: [116, 117, 118])hơn các lựa chọn thay thế như chữ ký ngưỡng Schnorr [202] hoặc BLS [55]. Môi trường thực thi đáng tin cậy (TEE): TEE là môi trường thực thi biệt lập (thường được thực hiện bằng phần cứng) nhằm mục đích cung cấp các biện pháp bảo vệ an ninh mạnh mẽ cho các chương trình đang chạy bên trong. Một số TEE (ví dụ: Intel SGX [84]) có thể tạo ra bằng chứng, được gọi là chứng thực, rằng đầu ra được tính toán chính xác bởi một chương trình cụ thể cho một đầu vào cụ thể12. Một biến thể đồng bộ hóa TEF dựa trên TEE có thể được triển khai bởi thay thế bằng chứng trong (zk-)rollups hoặc Validium bằng chứng thực TEE bằng kỹ thuật từ [80]. So với bằng chứng không có kiến thức được sử dụng trong rollups và Validium, TEE có nhiều hiệu quả hơn. So với việc ký ngưỡng, TEE loại bỏ sự phức tạp của tạo ra các chữ ký ECDSA ngưỡng vì về nguyên tắc chỉ cần một TEE có liên quan. Tuy nhiên, việc sử dụng TEE sẽ đưa ra thêm các giả định về độ tin cậy phụ thuộc vào phần cứng. Người ta cũng có thể kết hợp TEE với việc ký ngưỡng để tạo khả năng phục hồi chống lại sự xâm phạm của một phần nhỏ các trường hợp TEE, mặc dù biện pháp bảo vệ này giới thiệu lại sự phức tạp của việc tạo chữ ký ECDSA ngưỡng. Tính linh hoạt bổ sung: Các tùy chọn đồng bộ hóa này có thể được tinh chỉnh để mang lại sự linh hoạt hơn theo những cách sau. • Kích hoạt linh hoạt: Ứng dụng TEF có thể xác định các điều kiện đồng bộ hóa được kích hoạt. Ví dụ: việc đồng bộ hóa có thể dựa trên hàng loạt, ví dụ: xảy ra sau mọi N giao dịch, dựa trên thời gian, ví dụ: cứ sau 10 khối hoặc dựa trên sự kiện, ví dụ: xảy ra bất cứ khi nào giá tài sản mục tiêu thay đổi đáng kể. • Đồng bộ hóa một phần: Có thể và trong một số trường hợp là mong muốn (ví dụ: với rollups, đồng bộ hóa một phần có thể giảm độ trễ) để mong muốn cung cấp khả năng đồng bộ hóa nhanh các nội dung nhỏ lượng trạng thái, có lẽ chỉ thực hiện đồng bộ hóa đầy đủ theo định kỳ. Ví dụ, ngoại trừ có thể phê duyệt yêu cầu rút tiền bằng cách cập nhật số dư của người dùng trong SCa mà không cập nhật trạng thái MAINCHAIN. 6,4 tổ chức lại Tổ chức lại chuỗi khối do mất ổn định mạng hoặc thậm chí từ các cuộc tấn công 51% có thể gây ra mối đe dọa cho tính toàn vẹn của chuỗi chính. Trong thực tế, đối thủ đã sử dụng chúng để thực hiện các cuộc tấn công chi tiêu gấp đôi [34]. Trong khi các cuộc tấn công như vậy vào các chuỗi lớn là thách thức để gắn kết, chúng vẫn khả thi đối với một số chuỗi [88]. Vì nó hoạt động độc lập với MAINCHAIN nên DON mang đến những điều thú vị khả năng quan sát và cung cấp một số biện pháp bảo vệ chống lại việc tổ chức lại liên quan đến các cuộc tấn công. Ví dụ: DON có thể báo cáo cho một hợp đồng dựa trên SC trên MAINCHAIN ​​về sự tồn tại của một nhánh phân nhánh cạnh tranh có độ dài ngưỡng nào đó τ. Ngoài ra DON có thể 12Chi tiết bổ sung có thể được tìm thấy trong Phụ lục B.2.1. Họ không cần thiết cho sự hiểu biết.

cung cấp bằng chứng—trong cài đặt PoW hoặc PoS—về sự tồn tại của một đợt phân nhánh như vậy. các hợp đồng SC có thể thực hiện các hành động phòng thủ phù hợp, chẳng hạn như tạm dừng thực hiện giao dịch tiếp theo trong một khoảng thời gian (ví dụ: để cho phép các sàn giao dịch đưa vào danh sách đen chi tiêu gấp đôi tài sản). Lưu ý rằng mặc dù đối thủ tiến hành tấn công 51% có thể tìm cách kiểm duyệt báo cáo từ DON, biện pháp đối phó trong SC là yêu cầu báo cáo định kỳ từ DON để xử lý các giao dịch (tức là nhịp tim) hoặc để yêu cầu báo cáo mới cho xác thực một giao dịch có giá trị cao. Mặc dù các cảnh báo phân nhánh như vậy về nguyên tắc là một dịch vụ chung mà DON có thể cung cấp vì bất kỳ mục đích nào, kế hoạch của chúng tôi là kết hợp chúng với TEF.

DON トランザクション実行フレームワーク

(DON-TEF) DONs は、oracle とレイヤー 2 ソリューションの分散リソース サポートを提供します。 Decentralized Oracle Network Transaction-Execution Framework (DONTEF)、または略して TEF と呼ばれるもの。 現在、DeFi コントラクトの更新頻度はメイン チェーンのレイテンシによって制限されています。 たとえば、Ethereum [104] の 10 ～ 15 秒の平均ブロック間隔と、 大量のデータをチェーン上にプッシュし、計算/送信スループットが制限される— シャーディング [148、158、232] やレイヤー 2 実行 [5、 12、121、141、169、186、187]。トランザクション時間がはるかに速い blockchain であっても、 例: [120] は、オフチェーン計算 [168] を含むスケーリング戦略を提案しています。 TEF は、そのようなレイヤー 1 / MAINCHAIN システムのレイヤー 2 リソースとして機能することを目的としています。 TEF を使用すると、DONs は MAINCHAIN コントラクトでのより高速な更新をサポートできます。 メインチェーンによって提供される主要な信頼保証を保持します。 TEFがサポートできるのは rollups を含む、多数のレイヤー 2 実行技術およびパラダイムのいずれか、11 楽観的な rollups、Validium など、および DON が含まれるしきい値信頼モデル ノードはトランザクションを実行します。 TEF は FSS を補完するものであり、FSS をサポートすることを目的としています。言い換えれば、どれでも TEF で実行されているアプリケーションは FSS を使用できます。 11しばしば「zk-rollups」と呼ばれますが、これはゼロ知識証明を必ずしも必要としないため、誤った名称です。

Transaction Execution Framework schematic showing mempool, clearing, and settlement flow

6.1 TEFの概要 TEF は、パフォーマンスの高いハイブリッドを構築および実行するための設計パターンです。 smart contract SC。 ハイブリッド smart contracts の背後にある主な考え方に従って、TEF には以下が含まれます。 SC を 2 つの部分に分解: (1) TEF コンテキストでアンカーと呼ぶもの MAINCHAIN 上の契約 SCa と (2) DON ロジックは、TEF 実行可能ファイルと呼ばれます。 ここでは、SCa の組み合わせによって実装される論理コントラクトを示すために SC を使用します。 そして実行します。 (上で述べたように、私たちは、 SC をこれらのコンポーネントに自動的に契約します)。 TEF 実行可能ファイル exect は、SC でユーザーのトランザクションを処理するエンジンです。それ DON 上で実行されるため、パフォーマンスの高い方法で実行できます。これにはいくつかの機能があります。 • トランザクションの取り込み: exect はユーザーのトランザクションを受信または取得します。それはできる 直接、つまり、DON でのトランザクション送信を通じて、または MAINCHAIN 経由で MSを使用したmempool。 • 高速トランザクション実行: 内部の資産に関係するトランザクションを実行します。 SC。これはローカル、つまり DON 上で行われます。 • 高速かつ低コスト oracle / アダプター アクセス: exect は oracle レポートにネイティブ アクセスします。 およびその他のアダプター データにより、より高速、より安価、より正確な資産を実現 MAINCHAIN 実行よりも価格設定が異なります。さらに、オフチェーン oracle アクセスは減少します oracle の運用コスト、つまりシステムの使用コストを回避することで、 高価なオンチェーンストレージ。 • 同期: exect は定期的に更新を DON から MAINCHAIN にプッシュし、SCa を更新します。 アンカー コントラクトは、SC の MAINCHAIN フロント エンドです。 SC の高信頼コンポーネントとして、次のようないくつかの目的を果たします。 • 資産保管: ユーザーの資金は SCa に預け入れ、保持され、SCa から引き出しられます。 • 同期検証: SCa は、実行時に状態更新の正確さを検証する場合があります。 同期 (例: rollups に接続された SNARK)。 • ガード レール: SCa には、破損や障害から保護するための規定が含まれる場合があります。 実際に。 (詳細についてはセクション 7 を参照してください。) TEF では、ユーザーの資金は MAINCHAIN で保管されます。つまり、DON 自体は保管されていません。同期メカニズム (以下を参照) の選択に応じて、ユーザーは次のことが必要になる場合があります。 DON は、正確な oracle レポートと MAINCHAIN とのタイムリーな同期に対してのみ信頼されます。 結果として得られる信頼モデルは、オーダーブックベースの DEX のものと非常によく似ています (例: [2])。 現在、これには通常、注文照合用のオフチェーン コンポーネントと清算と決済用のオンチェーン コンポーネントが含まれています。決済システムの用語を使用すると、ex をコンポーネントと考えることができます。 SC が清算を担当し、SCa が決済を担当します。回路図については図 13 を参照してください。 TEFの描写。 図 13: TEF の回路図。この例では、トランザクションは mempool を通過します。 MAINCHAIN を MS 経由で DON に送信します。 TEF の利点: TEF には 3 つの主な利点があります。 • 高パフォーマンス: SC は、DON の MAINCHAIN よりもはるかに高いスループットを継承します。 トランザクションとoracleレポートの両方。さらに、exect は、MAINCHAIN のみでの実装よりもトランザクションをより速く処理し、oracle レポートにタイムリーに応答できます。 • 低料金: 同期プロセスはトランザクション処理ほど時間に依存せず、トランザクションは DON から MAINCHAIN にバッチで送信できます。 その結果、このアプローチによるトランザクションごとのオンチェーン料金 (ガスコストなど) は、MAINCHAIN 上でのみ実行されるコントラクトよりもはるかに低くなります。 • 機密性: DON の機密性メカニズムは、 SCでベア。

TEF の制限: TEF の制限の 1 つは、瞬間的なデータをサポートしていないことです。 引き出しはメインチェーン上でのみ発生します: 引き出しリクエストの送信時 SCa に対して、ユーザーは exect を含む状態更新を実行するまで待機する必要がある場合があります。 出金トランザクションが承認される前に行われます。いくつかの部分的な救済策について説明します。 ただし、セクション 6.2 に記載されています。 TEF のもう 1 つの制限は、DeFi の原子構成をサポートしていないことです。 MAINCHAIN 上のコントラクト、具体的には複数の DeFi を介してアセットをルーティングする機能 単一のトランザクションで契約します。ただし、TEF は、そのようなアトミック性をサポートできます。 DeFi 契約は同じ DON で実行されます。これに対処するいくつかの方法についても説明します セクション 6.2 の問題。 6.2 トランザクションルーティング SC のトランザクションは、ユーザーが DON に直接送信することも、経由してルーティングすることもできます。 MAINCHAIN の mempool (FSS 経由)。 4 つの異なるトランザクション タイプがあり、それぞれ 異なる処理が必要になる場合があります。 契約内取引: TEF はガス力学の複雑さを回避するため、SC にトランザクション処理の柔軟性を提供します。 レイヤ 1 契約で利用可能です。たとえば、Ethereum のメモリプール トランザクション中、 より高いガス価格の新しいトランザクションによって上書きされる可能性があり、SC は、SC 内の資産を操作するトランザクションが表示されるとすぐに、権限のあるトランザクションとして扱うことができます。 メンプールで。したがって、SC はトランザクションが確認されるまで待つ必要がありません。 ブロック内で実行されるため、レイテンシが大幅に短縮されます。 プロキシ: ユーザーは、ウォレットコントラクト経由でトランザクション τ を SC に送信するか、または MAINCHAIN 上の他のコントラクト。 DON は次の実行をシミュレートすることができます。 MAINCHAIN の τ を調べて、SC への後続トランザクションが発生するかどうかを判断します。 そうである場合、τ は、実行する SC の他のトランザクションと順序付けできます。いくつかあります DON がそのようなトランザクションを識別する方法の可能性: (1) DON はシミュレートできます。 メモリプール内のすべてのトランザクション (高価なアプローチ)。 (2) 特定の契約または ウォレットなどの契約タイプは、DON による監視のためにリストに登録できます。または (3) ユーザーは次のことができます。 DON 検査のためにトランザクションに注釈を付けます。 1 つのトランザクションが 2 つのトランザクションと相互作用する場合、問題はさらに複雑になります。 契約、SC1 および SC2 は、どちらも Fair Sequencing Services を使用しており、互換性のない注文ポリシーを持っています。 DON は、たとえば、最も遅い時間に τ をシーケンスする可能性があります。 それは両方と互換性があります。 預金: MAINCHAIN アセットを SC に預けるトランザクションは、SC がそれを有効なものとして扱う前に、ブロック内で確認される必要があります。マイニングを検出すると、 資産（例：イーサ）をSCaに送信するトランザクションを実行すると、即座に確認できます。デポジット。たとえば、oracle によって報告された DON の現在の価格を、 資産。 引き出し: 上で述べたように、TEF には出金が常に瞬時に実行できるとは限らないという制限があります。 rollup タイプの実行モデルでは、引き出しは 安全に実行するには、リクエストを他のトランザクションと並べる、つまりロールアップする必要があります。 加工された。ただし、この制限には部分的な解決策がいくつかあります。 DON が出金トランザクションまでの rollup 有効性証明を迅速に計算できる場合、メモリプール exect 内のユーザーのトランザクション τ を観察することで、より高いガス価格で τ の状態更新トランザクション τ ' を送信できます。これは一種の有益なフロントランニングです。 τ ' がメモリプールに到達する前に τ がマイニングされない場合、τ ' は τ に先行し、τ は 承認された引き出しが有効になります。 TEF バリアントでは、状態の更新を計算するために DON が使用されます (「 以下のしきい値署名バリアント)、DON は代わりにオフチェーンを決定することもできます 実行時の SC の状態を考慮して τ を承認すべきかどうか。 DON その後、完全なトランザクションに影響を与えることなく、出金 τ を承認するトランザクション τ ' を送信できます。 状態の更新。 このアプローチが不可能な場合、または成功しない場合は、DON によって開始される トランザクション τ ' は、τ に応答してユーザーに資金を送信できるため、ユーザーはその必要がなくなります。 追加のトランザクションを開始します。 6.3 同期中 TEF 実行可能ファイル exect は、更新を DON から MAINCHAIN に定期的にプッシュします。 同期と呼ばれるプロセスで SCa の状態を更新します。同期が考えられる レイヤ 2 トランザクションのレイヤ 1 への伝播として、TEF は任意の数を利用できます。 rollups [5, 12, 16, 69] を含む、この目的のための既存の手法の楽観的 rollups [10, 11, 141]、Validium [201]、または基本的なしきい値署名 (しきい値 BLS など) Schnorr、または ECDSA [24、54、116、202]。原則として、信頼できる実行環境 状態変化の正確性を証明することもでき、より高いパフォーマンスを提供します。 rollups の代替ですが、ハードウェアに依存する信頼モデルを使用します。 (例: [80] を参照。) 以下では、これらの同期オプションを 3 つの主要なプロパティに関して比較します。 テフ: • データの可用性: SC の状態はどこに保存されますか?少なくとも 3 つの選択肢があります TEF で利用可能: MAINCHAIN、DON、またはサードパーティのストレージで利用可能 IPFS などのプロバイダー。さまざまなセキュリティ保証と可用性を実現します レベルとパフォーマンスプロファイル。簡単に言えば、MAINCHAIN に状態を保存すると、 オンチェーンの監査可能性により、状態の可用性を第三者に依存する必要がなくなります。 一方、状態をオフチェーンに保存すると、ストレージコストが削減され、パフォーマンスが向上します。 スループットは、ストレージプロバイダー (DON またはサードパーティ) を信頼することを犠牲にして、 データの可用性。もちろん、これらのオプションを組み合わせた柔軟なモデルも可能です。 可能です。データ利用に必要な形式を表 1 に示します。• 正確性の保証: SCa は更新の正確さをどのように確認しますか exによってプッシュされましたか？これは exect と SCa の計算負荷に影響します。 同期遅延 (下記を参照)。 • 遅延: 同期の遅延には 3 つの要因があります: (1) 所要時間 同期トランザクション τsync を生成する予定です。 (2) τsyncにかかる時間 MAINCHAIN で確認します。 (3) τsync が有効になるまでの時間 ＳＣａ． TEF では、レイテンシーは出金の場合に特に重要です (ただし、出金の場合はそれほど重要ではありません)。 契約内取引）のため、出金には必ず（少なくとも 部分的）状態の同期。 同期中 オプション データ 可用性 正しさ 保証する レイテンシ ロールアップ [5、12、16、69] オンチェーン 有効性の証明 生成にかかる時間 有効性の証明 (例: 現在のシステムの分) バリジウム [201] オフチェーン 有効性の証明 同上 楽観的 rollup [10, 11、141] オンチェーン 不正行為の証拠 チャレンジの長さ 期間 (例: 日 または 週間） しきい値署名 [24, 54、116、202] 柔軟な DON によるしきい値署名 瞬時 信頼できる実行環境 [80] 柔軟な ハードウェアベース 証明書 瞬時 表 1: TEF のさまざまな同期オプションとそのプロパティ。 表 1 は、TEF の 5 つの主要な同期オプションのこれらのプロパティをまとめたものです。 （注） これらのテクノロジーをスタンドアロンのレイヤー 2 スケーリングとして比較するつもりはありません。 ソリューション。これについては、[121] などを参照してください。) 次に、各同期オプションについて説明します。 ロールアップ: rollup [69] は、状態遷移が トランザクションのバッチはオフチェーンで計算されます。 その後、状態の変化が伝播されます メインチェーンに。 rollups を実装するために、アンカー smart contract SCa は、実際の状態のコンパクト表現 Rstate (マークル ルートなど) を格納します。同期するには、τsync = を送信します。 (T、R' state) を SCa に変換します。ここで、T は、前回のトランザクション以降に処理されたトランザクションのセットです。同期とR' 状態は、次の方法を適用して計算された新しい状態のコンパクトな表現です。 T のトランザクションを前の状態 Rstate に戻します。 SCa が τsync での状態更新を検証する方法が異なる 2 つの一般的な亜種があります。 最初の (zk-)rollups は、正確性の簡潔な引数を添付します。 遷移 Rstate →R' の妥当性証明 状態。このバリアントを実装するには、次を実行します τsync とともに有効性証明 (zk-SNARK 証明など) を計算して送信します。 R'を証明する state は、SCa の現在の状態に T を適用した結果です。アンカー 契約は証拠を検証した後にのみ状態の更新を受け入れます。 楽観的な rollup には正しさの引数が含まれていませんが、staking と 状態遷移の分散検証を容易にするチャレンジ手順。このために rollup のバリアント、SCa は τsync が正しいと仮定して暫定的に受け入れます (したがって楽観的です) ただし、τsync はチャレンジ期間が終わるまで有効になりません。 MAINCHAIN を監視すると、誤った状態更新を特定し、SCa に通知することができます。 必要なアクション (例: 状態をロールバックし、実行時にペナルティを課す) 両方の rollup バリアントは、トランザクションがポストされるため、オンチェーン データの可用性を実現します。 オンチェーンから完全な状態を構築できます。 zk-rollups のレイテンシは 有効性証明を生成するのに必要な時間が大半を占め、通常は 既存のシステム [16] では数分のオーダーであり、時間の経過とともに改善される可能性があります。 一方、楽観的な rollup の遅延は長くなります (例: 数日または数週間)。 不正行為の証明が機能するには、異議申し立て期間が十分に長い必要があるためです。の 確認が遅いことの意味は微妙であり、場合によってはスキームに特有のものであるため、 徹底的な分析は範囲外です。たとえば、特定のスキームでは支払いが考慮されています。 状態の更新が確認される前に、トランザクションは「トラストレス最終」[109] として保存されます。 通常のユーザーは、MAINCHAIN よりもはるかに迅速に rollup を検証できます。 バリジウム: Validium は、データをオフチェーンのみで利用できるようにする (zk-)rollup の形式です すべてのデータを MAINCHAIN 上に維持するわけではありません。具体的には、 exect は新しいもののみを送信します 状態と証拠は提供されますが、SCa への取引は提供されません。 Validium スタイルの同期では、次のようになります。 完全な状態を保存するのは、それを実行する DON だけです。 トランザクションを実行するもの。 zk-rollups と同様、同期の遅延は有効性によって左右されます。 証拠の生成時間。ただし、zk-rollups とは異なり、Validium スタイルの同期により、 ストレージコストが削減され、スループットが向上します。 DON によるしきい値署名: DON ノードのしきい値が正しいと仮定すると、 シンプルで高速な同期オプションは、DON ノードが集合的に新しい状態に署名することです。 このアプローチは、オンチェーンとオフチェーンの両方のデータ可用性をサポートできます。場合に注意してください。 ユーザーは oracle アップデートに対して DON を信頼します。受け入れるためにそれ以上信頼する必要はありません 状態の更新は、すでにしきい値信頼モデルに含まれているためです。 もう一つの利点は、 しきい値署名は低遅延です。新しいトランザクション署名形式のサポート EIP-2938 [70] で提案され、アカウント抽象化として知られているしきい値が作成されます。 署名はしきい値の必要性を排除するため、実装が大幅に容易になります。 ECDSA。かなり複雑なプロトコルが含まれます (例: [116、117、118])しきい値 Schnorr [202] 署名や BLS [55] 署名などの代替署名よりも優れています。 信頼された実行環境 (TEE): TEE は、強力なセキュリティ保護を提供することを目的とした分離された実行環境 (通常はハードウェアによって実現される) です。 内部で実行されているプログラム用。一部の TEE (例: Intel SGX [84]) はプルーフを生成できます。 証明書として知られ、出力が特定のプログラムによって正しく計算されていることを示します。 特定の入力12. TEE ベースの TEF 同期のバリアントは、次のように実装できます。 (zk-)rollups または Validium の証明をテクニックを使用した TEE 証明書に置き換える [80] から。 rollups や Validium で使用されるゼロ知識証明と比較すると、TEE ははるかに優れています。 より高性能に。しきい値署名と比較して、TEE は複雑さを解消します。 原則として必要な TEE は 1 つだけであるため、しきい値 ECDSA 署名を生成する 関与している。ただし、TEE を使用すると、ハードウェアに依存する追加の信頼仮定が導入されます。 TEE としきい値署名を組み合わせて回復力を生み出すこともできます この保護措置は、TEE インスタンスの一部の侵害に対しては適用されますが、 しきい値 ECDSA 署名の生成の複雑さが再び導入されます。 追加の柔軟性: これらの同期オプションは、次の方法でさらに柔軟に調整できるようになります。 • 柔軟なトリガー: TEF アプリケーションは、次の条件を決定できます。 同期がトリガーされます。たとえば、同期はバッチベースで行うことができます。 N トランザクションごと、時間ベース (例: 10 ブロックごと)、またはイベントベース (例: 発生) 目標資産価格が大きく変動するときはいつでも。 • 部分的な同期: 可能であり、場合によっては望ましい場合もあります (例: rollups、 部分的な同期によりレイテンシを短縮できます）。小規模な同期の高速同期を実現します。 完全な同期はおそらく定期的にのみ実行されます。たとえば、 実行者は、SCa のユーザーの残高を更新することで出金リクエストを承認できます それ以外の方法で MAINCHAIN 状態を更新する必要はありません。 6.4 再組織化 ネットワークの不安定性、または 51% 攻撃によっても引き起こされるブロックチェーンの再編成 メインチェーンの整合性に脅威を与える可能性があります。実際、敵対者はこれを使用してきました。 二重支出攻撃[34]を仕掛けるためです。大手チェーンに対するこのような攻撃は、 取り付けるのは難しいですが、一部のチェーン [88] では依然として実現可能です。 DON は MAINCHAIN から独立して動作するため、興味深い機能を提供します。 に関連する組織再編を観察し、それに対して何らかの保護を提供する可能性 攻撃します。 たとえば、DON は、MAINCHAIN 上の依存コントラクト SC に、あるしきい値長 τ の競合フォークの存在を報告できます。 DON ではさらに、 12補足の詳細については、付録 B.2.1 を参照してください。理解するためには必要ありません。

PoW または PoS 設定のいずれかで、そのようなフォークの存在の証拠を提供します。の 契約SCは、さらなるトランザクション実行を一定期間停止するなど、適切な防御措置を実装することができます（たとえば、取引所が二重支出をブラックリストに登録できるようにするため） 資産）。 51% 攻撃を仕掛ける敵は検閲を試みることができることに注意してください。 DON からの報告がある場合、SC の対策としては、DON からの定期的な報告を要求することです。 DON トランザクション (ハートビートなど) を処理するため、または新しいレポートを要求するため 高額な取引を検証します。 このような分岐アラートは原則として、DON が提供できる一般的なサービスです。 さまざまな目的のために、私たちの計画はそれらを TEF に組み込むことです。

Giảm thiểu sự tin cậy

Là một hệ thống phi tập trung với sự tham gia của một tập hợp các thực thể không đồng nhất, Mạng Chainlink cung cấp khả năng bảo vệ mạnh mẽ chống lại các lỗi về cả tính khả dụng (tính khả dụng) và độ an toàn (tính toàn vẹn của báo cáo). Tuy nhiên, hầu hết các hệ thống phi tập trung đều khác nhau về mức độ mà các thành phần cấu thành của chúng được phân cấp. Cái này đúng ngay cả với các hệ thống lớn, nơi có sự phân quyền hạn chế giữa các thợ mỏ [32] và trung gian [51] đã có mặt từ lâu. Mục tiêu của bất kỳ nỗ lực phân cấp nào là giảm thiểu sự tin cậy: Chúng tôi tìm cách giảm tác động bất lợi của tham nhũng hoặc trục trặc hệ thống trong mạng Chainlink, thậm chí cả điều đó do DON độc hại. Nguyên tắc chỉ đạo của chúng tôi là Nguyên tắc đặc quyền tối thiểu [197]. Các thành phần và tác nhân hệ thống trong hệ thống phải có đặc quyền trong phạm vi nghiêm ngặt chỉ cho phép hoàn thành thành công vai trò được giao của họ. Ở đây chúng tôi trình bày một số cơ chế cụ thể để Chainlink áp dụng trong quá trình phát triển của nó hướng tới việc giảm thiểu sự tin cậy ngày càng lớn hơn. Chúng tôi mô tả các cơ chế này theo thuật ngữ của locus, tức là các thành phần hệ thống mà chúng có gốc rễ, được hiển thị trong Hình 14. Chúng ta giải quyết từng địa điểm trong một tiểu mục tương ứng. 7.1 Xác thực nguồn dữ liệu Mô hình hoạt động hiện tại cho oracle bị hạn chế bởi thực tế là có ít nguồn dữ liệu ký điện tử vào dữ liệu họ bỏ qua, phần lớn là do TLS không ký tự nhiên dữ liệu. TLS sử dụng chữ ký số trong giao thức “bắt tay” của nó (để thiết lập khóa chung giữa máy chủ và máy khách). Do đó, các máy chủ hỗ trợ HTTPS có chứng chỉ trên các khóa công khai về nguyên tắc có thể dùng để ký dữ liệu, nhưng chúng thường không sử dụng những chứng chỉ này để hỗ trợ việc ký dữ liệu. Do đó, tính bảo mật của DON, như trong các mạng oracle ngày nay, dựa vào các nút oracle chuyển tiếp dữ liệu một cách trung thực từ một mạng dữ liệu nguồn cho một hợp đồng. Một thành phần quan trọng lâu dài trong tầm nhìn của chúng tôi nhằm giảm thiểu sự tin cậy trong Chainlink liên quan đến việc xác thực nguồn dữ liệu mạnh mẽ hơn thông qua việc hỗ trợ các công cụ và tiêu chuẩn để ký dữ liệu. Việc ký dữ liệu có thể giúp thực thi các đảm bảo tính toàn vẹn từ đầu đến cuối. Về nguyên tắc, nếu một hợp đồng chấp nhận đầu vào là một phần dữ liệu D được ký trực tiếp bởi bên dữ liệu.

Loci of trust-minimizing mechanisms in the Chainlink network showing data quality, node selection, and oracle report verification

Hình 14: Các cơ chế giảm thiểu sự tin cậy được thảo luận trong phần này. 1⃝Dữ liệu các nguồn cung cấp dữ liệu cho 2⃝DON, chuyển tiếp chức năng của dữ liệu đến bộ phận phụ thuộc 3⃝smart contract. Ngoài ra, mạng DON hoặc oracle bao gồm 4⃝nút quản lý smart contract trên MAINCHAIN, ví dụ: các nút bù, bảo vệ đường ray, vân vân. nguồn thì mạng oracle không thể giả mạo D. Có nhiều lời khuyến khích khác nhau những nỗ lực cho phép việc ký dữ liệu như vậy đã xuất hiện, bao gồm cả OpenID Connect, được thiết kế chủ yếu để xác thực người dùng [9], TLS-N, một dự án học thuật nhằm mục đích mở rộng TLS [191] bằng cách sử dụng lại chứng chỉ TLS và Tiện ích mở rộng bằng chứng TLS [63]. Tuy nhiên, mặc dù OpenID Connect đã được áp dụng một số, nhưng Tiện ích mở rộng bằng chứng TLS và TLS-N vẫn chưa được áp dụng. Một cách xác thực nguồn dữ liệu tiềm năng khác là sử dụng Trao đổi HTTP đã ký (SXG) [230], họ có thể lưu vào bộ nhớ đệm trên mạng phân phối nội dung như một phần của giao thức Trang di động tăng tốc (AMP) [225]. Trình duyệt dành cho thiết bị di động Chrome hiển thị nội dung từ SXG được lưu trong bộ nhớ đệm AMP như thể chúng được phân phát từ miền mạng riêng của nhà xuất bản của họ thay vì miền máy chủ bộ đệm. Khuyến khích xây dựng thương hiệu này, cùng với việc tương đối dễ dàng cho phép nó sử dụng các dịch vụ như URL thực của CloudFlare [83] và amppackager [124] của Google, có thể dẫn đến việc áp dụng rộng rãi SXG trong nội dung tin tức được lưu trong bộ nhớ đệm, điều này sẽ cho phép một quy trình đơn giản, chống giả mạo cách để Chainlink oracle kích hoạt các sự kiện đáng chú ý được báo cáo trong SXG hợp lệ. Mặc dù SXG được lưu trong bộ nhớ đệm AMP từ các nhà xuất bản tin tức sẽ không hữu ích cho các ứng dụng có nhịp độ cao. các ứng dụng như báo cáo về dữ liệu giao dịch, chúng có thể là nguồn an toàn cho các giao dịch tùy chỉnh. các hợp đồng liên quan đến các sự kiện trong thế giới thực như thời tiết khắc nghiệt hoặc kết quả bầu cử. Chúng tôi tin rằng việc triển khai đơn giản, các công cụ hoàn thiện và tính linh hoạt sẽ rất quan trọng đối với tăng tốc việc ký nguồn dữ liệu. Cho phép nhà cung cấp dữ liệu sử dụng các nút Chainlink làm giao diện người dùng API được xác thực có vẻ là một cách tiếp cận đầy hứa hẹn. Chúng tôi dự định tạo ra mộttùy chọn cho các nút hoạt động ở chế độ này, có hoặc không có sự tham gia vào mạng dưới dạng oracle toàn diện. Chúng tôi gọi khả năng này là nguồn gốc dữ liệu được xác thực (ADO). Bằng cách sử dụng các nút Chainlink với ADO, các nguồn dữ liệu sẽ có thể được hưởng lợi từ kinh nghiệm và công cụ do cộng đồng Chainlink phát triển trong việc bổ sung kỹ thuật số khả năng ký kết vào bộ API ngoài chuỗi hiện có của họ. Liệu họ có nên chọn chạy các nút của họ dưới dạng oracle, họ cũng có thể mở ra các luồng doanh thu mới tiềm năng theo cùng mô hình với các nhà cung cấp dữ liệu hiện có, ví dụ: Kraken [28], Kaiko [140] và những người khác chạy các nút Chainlink để bán dữ liệu API trên chuỗi. 7.1.1 Những hạn chế của nguồn gốc dữ liệu được xác thực Ký kỹ thuật số bằng nguồn dữ liệu, mặc dù có thể giúp tăng cường xác thực nhưng bản chất nó không đủ để thực hiện tất cả các mục tiêu hoạt động hoặc bảo mật tự nhiên của oracle mạng. Đầu tiên, một phần dữ liệu D nhất định vẫn phải được chuyển tiếp một cách mạnh mẽ và kịp thời. cách từ nguồn dữ liệu tới smart contract hoặc người tiêu dùng dữ liệu khác. Tức là ngay cả trong một cài đặt lý tưởng trong đó tất cả dữ liệu được ký bằng các khóa được lập trình sẵn thành phụ thuộc hợp đồng, vẫn cần có DON để truyền đạt dữ liệu một cách đáng tin cậy từ các nguồn đến các hợp đồng. Ngoài ra, có một số trường hợp trong đó hợp đồng hoặc dữ liệu oracle khác người tiêu dùng muốn truy cập vào đầu ra được xác thực của các chức năng khác nhau được tính toán trên dữ liệu nguồn vì hai lý do chính: • Tính bảo mật: API nguồn dữ liệu có thể cung cấp dữ liệu nhạy cảm hoặc độc quyền cần phải được biên tập lại hoặc khử trùng trước khi nó được hiển thị công khai trên chuỗi. Tuy nhiên, bất kỳ sửa đổi nào đối với dữ liệu đã ký đều làm mất hiệu lực của chữ ký. Đặt cái khác Nói cách khác, ADO ngây thơ và việc dọn dẹp dữ liệu không tương thích. Chúng tôi hiển thị trong ví dụ 3 làm thế nào cả hai có thể được dung hòa thông qua một hình thức ADO nâng cao. • Lỗi nguồn dữ liệu: Cả lỗi và lỗi đều có thể ảnh hưởng đến nguồn dữ liệu và chữ ký số không giải quyết được vấn đề gì. Từ khi thành lập [98], Chainlink đã đã bao gồm một cơ chế để khắc phục những lỗi đó: sự dư thừa. Báo cáo do mạng oracle đưa ra thường trình bày dữ liệu kết hợp của nhiều nguồn. Bây giờ chúng tôi thảo luận về các kế hoạch mà chúng tôi đang khám phá trong cài đặt ADO để nâng cao tính bảo mật của dữ liệu nguồn và kết hợp dữ liệu từ nhiều nguồn một cách an toàn. 7.1.2 Tính bảo mật Các nguồn dữ liệu có thể không dự đoán và cung cấp đầy đủ các API mong muốn bởi người dùng. Cụ thể, người dùng có thể muốn truy cập dữ liệu được xử lý trước để giúp đảm bảo tính bảo mật. Ví dụ sau đây minh họa vấn đề.Ví dụ 3. Alice mong muốn có được thông tin xác thực danh tính phi tập trung (DID) nêu rõ rằng cô ấy trên 18 tuổi (và do đó, chẳng hạn, có thể vay tiền). để làm vì vậy, cô ấy cần phải chứng minh sự thật này về tuổi của mình với tổ chức cấp chứng chỉ DID. Alice hy vọng sẽ sử dụng dữ liệu từ Bộ phương tiện cơ giới (DMV) của bang cô ấy trang web cho mục đích này. DMV có hồ sơ về ngày sinh của cô ấy và sẽ phát ra một chứng thực được ký điện tử A trên đó có dạng sau: A = {Tên: Alice, DoB: 16/02/1999}. Trong ví dụ này, chứng thực A có thể đủ để Alice chứng minh cho DID nhà cấp chứng chỉ xác thực rằng cô ấy trên 18 tuổi. Nhưng nó không cần thiết làm rò rỉ thông tin nhạy cảm: của Alice DoB chính xác. Lý tưởng nhất là điều Alice muốn từ DMV thay vào đó là chữ ký trên một câu nói đơn giản A′ rằng “Alice trên 18 tuổi.” Nói cách khác, cô ấy muốn đầu ra của hàm G vào ngày sinh của cô ấy X, trong đó (một cách không chính thức), A′ = G(X) = True nếu Ngày hiện tại −X ≥18 năm; ngược lại, G(X) = Sai. Để khái quát hóa, Alice muốn có thể yêu cầu từ nguồn dữ liệu một chứng thực A′ có dạng: A′ = {Tên: Alice, Func:G(X), Kết quả: Đúng}, trong đó G(X) biểu thị đặc tả của hàm G và (các) đầu vào X của nó. Chúng ta hình dung rằng người dùng sẽ có thể cung cấp G(X) mong muốn làm đầu vào cho yêu cầu của mình về chứng thực tương ứng A′. Lưu ý rằng chứng thực của nguồn dữ liệu A′ phải bao gồm thông số G(X) để đảm bảo rằng A′ được giải thích chính xác. Trong ví dụ trên, G(X) định nghĩa ý nghĩa của giá trị Boolean trong A′ và do đó True biểu thị chủ đề của chứng thực trên 18 tuổi. Chúng tôi đề cập đến các truy vấn linh hoạt trong đó người dùng có thể chỉ định G(X) làm truy vấn chức năng. Để hỗ trợ các trường hợp sử dụng như trong Ví dụ 3, cũng như các trường hợp liên quan đến truy vấn trực tiếp từ hợp đồng, chúng tôi dự định bao gồm hỗ trợ cho các truy vấn chức năng liên quan đến các hàm đơn giản G như một phần của ADO. 7.1.3 Kết hợp dữ liệu nguồn Để giảm chi phí trên chuỗi, các hợp đồng thường được thiết kế để sử dụng dữ liệu kết hợp từ nhiều nguồn, như được minh họa trong ví dụ sau. Ví dụ 4 (Trung gian hóa dữ liệu giá). Để cung cấp nguồn cấp giá, tức là giá trị của một tài sản (ví dụ: ETH) so với tài sản khác (ví dụ: USD), mạng oracle thường sẽ có được giá hiện tại từ một số nguồn, chẳng hạn như trao đổi. Mạng oracle thường gửi đến SC hợp đồng phụ thuộc giá trị trung bình của các giá trị này. Trong môi trường có ký dữ liệu, mạng oracle hoạt động chính xác sẽ nhận được từ nguồn dữ liệu S = {S1, . . . , SnS} dãy các giá trị V = {v1, v2, . . . , vnS} từ nS nguồn có chữ ký nguồn cụ thể đi kèm Σ = {σ1, σ2, . . . , σnS}. Khi xác minh chữ ký, nó truyền giá v = trung vị (V ) tới SC.Thật không may, không có cách đơn giản nào để mạng oracle truyền giá trị trung vị giá trị v trong Ví dụ 4 đến SC cùng với bằng chứng ngắn gọn σ∗rằng v đã được tính toán chính xác trên đầu vào đã ký. Một cách tiếp cận ngây thơ sẽ là mã hóa trong SC các khóa chung của tất cả các nguồn dữ liệu nS. Mạng oracle sau đó sẽ chuyển tiếp (V, Σ) và cho phép SC tính toán trung vị của V . Tuy nhiên, điều này sẽ dẫn đến một bằng chứng σ có kích thước O(nS)—tức là, σ∗sẽ không ngắn gọn. Nó cũng sẽ phải chịu chi phí gas cao cho SC, cần phải xác minh tất cả chữ ký trong Σ. Ngược lại, việc sử dụng SNARK cho phép chứng minh ngắn gọn về các giá trị nguồn được xác thực được kết hợp chính xác. Nó có thể khả thi trong thực tế, nhưng áp đặt khá cao chi phí tính toán trên bộ chuẩn và chi phí gas hơi cao trên dây chuyền. Sử dụng Town Crier cũng là một lựa chọn, nhưng yêu cầu sử dụng TEE, không phù hợp với tất cả mọi người. mô hình niềm tin của người dùng. Một khái niệm hữu ích để đưa ra các giải pháp cho vấn đề chung về ký dữ liệu kết hợp từ các nguồn là một công cụ mật mã được gọi là chữ ký chức năng [59, 132]. Tóm lại, chữ ký chức năng cho phép người ký ủy quyền khả năng ký, sao cho người được ủy quyền chỉ có thể ký các tin nhắn trong phạm vi chức năng F do người ký chọn. Chúng tôi trình bày trong Phụ lục D cách ràng buộc chức năng này có thể dùng để giới hạn phạm vi của các giá trị báo cáo do DON phát ra dưới dạng hàm của các giá trị được ký bởi nguồn dữ liệu. Chúng tôi cũng giới thiệu một dạng nguyên thủy mới, được gọi là chữ ký hàm rời rạc, bao gồm yêu cầu thoải mái về độ chính xác nhưng có khả năng hoạt động hiệu quả hơn nhiều. hơn các phương pháp tiếp cận như SNARK. Bài toán kết hợp các nguồn dữ liệu theo cách bao gồm xác thực nguồn của đầu ra cũng áp dụng cho các công cụ tổng hợp dữ liệu, ví dụ: CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, v.v., thu thập dữ liệu từ nhiều sàn giao dịch mà chúng trọng lượng dựa trên khối lượng, sử dụng các phương pháp mà trong một số trường hợp họ công bố và trong các trường hợp khác là độc quyền. Một trình tổng hợp muốn xuất bản một giá trị với xác thực nguồn phải đối mặt với thách thức tương tự như việc tập hợp các nút tổng hợp dữ liệu nguồn. 7.1.4 Đang xử lý dữ liệu nguồn smart contract phức tạp có thể phụ thuộc vào số liệu thống kê tổng hợp tùy chỉnh trên nguồn dữ liệu chính, chẳng hạn như sự biến động trong lịch sử giá gần đây của nhiều tài sản hoặc văn bản và hình ảnh từ tin tức về các sự kiện thích hợp. Vì khả năng tính toán và băng thông tương đối rẻ trong DON nên những thống kê này— ngay cả các mô hình học máy phức tạp có nhiều đầu vào—cũng có thể được xử lý một cách tiết kiệm, miễn là mọi giá trị đầu ra dành cho blockchain đều đủ ngắn gọn. Đối với các công việc đòi hỏi tính toán chuyên sâu trong đó DON người tham gia có thể có các ý kiến khác nhau quan điểm về đầu vào phức tạp, các vòng giao tiếp bổ sung giữa những người tham gia DON có thể được yêu cầu thiết lập sự đồng thuận về đầu vào trước khi tính toán kết quả. Miễn là giá trị cuối cùng được xác định đầy đủ bởi đầu vào, khi sự đồng thuận đầu vào được thiết lập, mỗi người tham gia có thể chỉ cần tính giá trị và truyền nó cho người khácngười tham gia bằng chữ ký một phần của họ hoặc gửi nó đến một công cụ tổng hợp. 7.2 DON Giảm thiểu sự tin cậy Chúng tôi hình dung hai cách chính để giảm thiểu sự tin cậy đặt vào các thành phần của DON: khách hàng chuyển đổi dự phòng và báo cáo thiểu số. 7.2.1 Khách hàng chuyển đổi dự phòng Các mô hình đối nghịch trong tài liệu về mật mã và hệ thống phân tán thường xem xét một đối thủ có khả năng làm hỏng (tức là xâm phạm) một tập hợp con các nút, ví dụ: ít hơn một phần ba đối với nhiều giao thức BFT. Tuy nhiên, người ta thường quan sát thấy, rằng nếu tất cả các nút chạy phần mềm giống hệt nhau, kẻ thù xác định được một lỗi khai thác nghiêm trọng có thể về nguyên tắc thỏa hiệp tất cả các nút ít nhiều cùng một lúc. Cài đặt này thường được gọi là độc canh phần mềm [47]. Nhiều đề xuất khác nhau về việc tự động đa dạng hóa phần mềm và cấu hình phần mềm đã được đưa ra để giải quyết vấn đề, ví dụ: [47, 113]. Như đã lưu ý trong [47], tuy nhiên, tính đa dạng của phần mềm là một vấn đề phức tạp và cần được xem xét cẩn thận. Ví dụ, đa dạng hóa phần mềm có thể dẫn đến tình trạng bảo mật kém hơn so với độc canh nếu nó tăng bề mặt tấn công của hệ thống và do đó các vectơ tấn công có thể vượt quá những lợi ích bảo mật mà nó mang lại. Chúng tôi tin rằng sự hỗ trợ dành cho các ứng dụng khách chuyển đổi dự phòng mạnh mẽ—tức là các ứng dụng khách với nút nào có thể chuyển đổi khi đối mặt với một sự kiện thảm khốc—là một hình thức đặc biệt hấp dẫn của đa dạng hóa phần mềm. Máy khách chuyển đổi dự phòng không làm tăng số lượng vectơ tiềm năng bị tấn công vì chúng không được triển khai như phần mềm chính. Chúng mang lại lợi ích rõ ràng, tuy nhiên, như một tuyến phòng thủ thứ hai. Chúng tôi dự định hỗ trợ các máy khách chuyển đổi dự phòng trong DONs như một phương tiện chính để giảm sự phụ thuộc vào bảo mật của họ vào một khách hàng. Chainlink đã có sẵn một hệ thống máy khách chuyển đổi dự phòng mạnh mẽ. Cách tiếp cận của chúng tôi liên quan đến việc duy trì các phiên bản máy khách đã được thử nghiệm trong trận chiến trước đó. Ví dụ: ngày nay, các nút Chainlink với Báo cáo chuỗi Off (OCR) là khách hàng chính của họ bao gồm hỗ trợ cho hệ thống FluxMonitor trước đó của Chainlink nếu cần. Đã được sử dụng một số hiện tại, FluxMonitor đã nhận được kiểm tra bảo mật và thử nghiệm hiện trường. Nó cung cấp tương tự chức năng như OCR, nhưng với chi phí cao hơn—chi phí chỉ phát sinh khi cần thiết. 7.2.2 Báo cáo thiểu số Với một tập hợp thiểu số đủ lớn Ominority—một phần nhỏ các nút trung thực quan sát thấy sự sai trái của đa số—việc chúng tạo ra thiểu số có thể hữu ích. báo cáo. Đây là một báo cáo hoặc cờ song song, được chuyển tiếp đến hợp đồng phụ thuộc SC trên chuỗi của Ominority. SC có thể sử dụng cờ này theo chính sách dành riêng cho hợp đồng của mình. Ví dụ: đối với một hợp đồng trong đó sự an toàn quan trọng hơn tính sống động hoặc khả năng đáp ứng, báo cáo thiểu số có thể khiến hợp đồng yêu cầu báo cáo bổ sung. từ DON khác hoặc kích hoạt cầu dao (xem phần tiếp theo).Báo cáo của thiểu số có thể đóng một vai trò quan trọng ngay cả khi đa số là trung thực, bởi vì bất kỳ sơ đồ tổng hợp báo cáo nào, ngay cả khi nó sử dụng chữ ký chức năng, đều phải hoạt động theo ngưỡng để đảm bảo khả năng phục hồi trước oracle hoặc lỗi dữ liệu. trong nói cách khác, phải có khả năng tạo ra một báo cáo hợp lệ dựa trên thông tin đầu vào của kS < nS oracles, đối với một số ngưỡng kS. Điều này có nghĩa là DON bị hỏng có một số vĩ độ trong việc thao tác các giá trị báo cáo bằng cách chọn các giá trị kS ưa thích của nó trong số nS được báo cáo trong V bởi tập hợp đầy đủ oracles, ngay cả khi tất cả các nguồn đều trung thực. Ví dụ, giả sử nS = 10 và kS = 7 trong hệ thống sử dụng hàm chữ ký để xác thực tính toán trung bình trên V đối với giá ETH bằng USD. Giả sử có năm nguồn báo cáo mức giá \(500, while the other five report \)1000. Sau đó, bằng cách tính trung bình 7 báo cáo thấp nhất, DON có thể tạo ra giá trị hợp lệ v = $500, và bằng cách tính trung bình mức cao nhất, nó có thể tạo ra v = $1000. Bằng cách nâng cao giao thức DON để tất cả các nút đều biết dữ liệu nào được có sẵn và dữ liệu nào được sử dụng để xây dựng báo cáo, các nút có thể phát hiện và gắn cờ xu hướng có ý nghĩa thống kê để ưu tiên một tập hợp báo cáo hơn tập hợp khác và tạo ra kết quả là một báo cáo thiểu số. 7.3 Đường ray bảo vệ Mô hình tin cậy của chúng tôi dành cho DON coi MAINCHAIN là đặc quyền cao hơn, bảo mật cao hơn hệ thống hơn DONs. (Mặc dù mô hình tin cậy này có thể không phải lúc nào cũng đúng nhưng nó dễ dàng hơn để điều chỉnh cơ chế kết quả cho phù hợp với các tình huống trong đó DON có độ bảo mật cao hơn nền tảng hơn là ngược lại.) Do đó, chiến lược giảm thiểu sự tin cậy tự nhiên bao gồm việc triển khai các cơ chế giám sát và an toàn dự phòng trong smart contracts—trong giao diện người dùng MAINCHAIN cho DON hoặc trực tiếp trong hợp đồng phụ thuộc SC. Chúng tôi gọi những cơ chế này là lan can bảo vệ và liệt kê một số điều quan trọng nhất ở đây: • Bộ ngắt mạch: SC có thể tạm dừng hoặc dừng cập nhật trạng thái do chức năng của các đặc điểm của chính bản cập nhật trạng thái đó (ví dụ: phương sai lớn giữa các lần cập nhật trạng thái báo cáo) hoặc dựa trên các đầu vào khác. Ví dụ, một cầu dao có thể ngắt điện các trường hợp trong đó báo cáo oracle thay đổi đáng kể theo thời gian. Bộ ngắt mạch có thể cũng bị vấp ngã bởi một báo cáo thiểu số. Do đó, bộ ngắt mạch có thể ngăn chặn DONs khỏi việc đưa ra những báo cáo sai lầm trầm trọng. Bộ ngắt mạch có thể cung cấp thời gian để xem xét các biện pháp can thiệp bổ sung hoặc tập thể dục. Một sự can thiệp như vậy là cửa thoát hiểm. • Cửa thoát hiểm: Trong các trường hợp bất lợi, được xác định bởi một nhóm người giám hộ, chủ sở hữu token cộng đồng hoặc các cơ quan quản trị khác, hợp đồng có thể viện dẫn cơ sở khẩn cấp đôi khi được gọi là cửa thoát hiểm [163]. Một lối thoát hiểm khiến SC tắt theo cách nào đó và/hoặc chấm dứt đang chờ xử lý và có thể các giao dịch trong tương lai. Ví dụ: nó có thể trả lại tiền được lưu ký cho người dùng [17]),có thể chấm dứt các điều khoản hợp đồng [162] hoặc có thể hủy các giao dịch đang chờ xử lý và/hoặc trong tương lai [173]. Cửa thoát hiểm có thể được triển khai trong bất kỳ loại hợp đồng nào, không chỉ một cái dựa trên DON, nhưng chúng được quan tâm như một bộ đệm tiềm năng chống lại DON sự cố. • Chuyển đổi dự phòng: Trong các hệ thống mà SC dựa vào DON cho các dịch vụ thiết yếu, SC có thể cung cấp cơ chế chuyển đổi dự phòng để đảm bảo dịch vụ luôn được tiếp tục trong trường hợp DON thất bại hoặc hành vi sai trái. Ví dụ: trong TEF (Phần 6), hợp đồng neo SCa có thể cung cấp giao diện kép trong đó cả trên chuỗi và Giao diện thực thi ngoài chuỗi được hỗ trợ cho một số hoạt động quan trọng nhất định (ví dụ: rút tiền) hoặc đối với các giao dịch thông thường, với độ trễ phù hợp để ngăn chặn việc chạy trước các giao dịch DON. Trong trường hợp nguồn dữ liệu ký dữ liệu, người dùng có thể cũng cung cấp báo cáo cho SCa khi DON không thực hiện được. Bằng chứng gian lận, như được đề xuất cho các hình thức lạc quan khác nhau rollup (xem Phần 6.3), có hương vị tương tự và bổ sung cho các cơ chế mà chúng tôi liệt kê ở trên. Họ cũng cung cấp một hình thức giám sát và bảo vệ trên chuỗi chống lại các lỗi tiềm ẩn trong các thành phần hệ thống ngoài chuỗi. 7.4 Quản trị tối thiểu hóa niềm tin Giống như tất cả các hệ thống phi tập trung, mạng Chainlink yêu cầu cơ chế quản trị để điều chỉnh các thông số theo thời gian, ứng phó với các trường hợp khẩn cấp và hướng dẫn sự phát triển của nó. Một số cơ chế này hiện có trên MAINCHAIN và có thể tiếp tục làm như vậy ngay cả khi triển khai DONs. Một ví dụ là cơ chế thanh toán dành cho nhà cung cấp nút oracle (DON nút). DON hợp đồng giao diện người dùng trên MAINCHAIN chứa các cơ chế bổ sung, chẳng hạn như đường ray bảo vệ, có thể phải chịu sự kiểm soát định kỳ sửa đổi. Chúng tôi thấy trước hai loại cơ chế quản trị: tiến hóa và khẩn cấp. Quản trị tiến hóa: Nhiều sửa đổi đối với hệ sinh thái Chainlink được thực hiện sao cho việc thực hiện chúng không phải là vấn đề cấp bách: Cải thiện hiệu suất, cải tiến tính năng, nâng cấp bảo mật (không khẩn cấp), v.v. Khi Chainlink dần dần hướng tới nhiều người tham gia hơn nữa vào việc quản trị, chúng tôi mong đợi nhiều hoặc hầu hết những thay đổi như vậy sẽ được phê chuẩn bởi cộng đồng DON cụ thể bị ảnh hưởng bởi những thay đổi đó những thay đổi. Tạm thời và có lẽ cuối cùng là một cơ chế song song, chúng tôi tin rằng rằng khái niệm về đặc quyền tối thiểu tạm thời có thể là một phương tiện hữu ích để thực hiện quản trị tiến hóa. Rất đơn giản, ý tưởng là những thay đổi sẽ được triển khai dần dần, đảm bảo cộng đồng có cơ hội đáp ứng lại chúng. Ví dụ: di chuyển sang một nơi mới Hợp đồng MAINCHAIN có thể bị hạn chế để hợp đồng mới phải được triển khai ít nhất ba mươi ngày trước khi kích hoạt.Quản lý khẩn cấp: Các lỗ hổng có thể bị khai thác hoặc bị khai thác trong MAINCHAIN hợp đồng hoặc các hình thức mất an toàn hoặc sự sống khác có thể yêu cầu can thiệp ngay lập tức để đảm bảo chống lại các hậu quả thảm khốc. Mục đích của chúng tôi là hỗ trợ multisig cơ chế can thiệp trong đó, để đảm bảo chống lại hành vi sai trái của bất kỳ tổ chức nào, người ký sẽ được phân tán khắp các tổ chức. Đảm bảo sự sẵn có nhất quán của người ký và tiếp cận kịp thời các chuỗi lệnh thích hợp để cấp phép cho tình huống khẩn cấp những thay đổi rõ ràng sẽ yêu cầu lập kế hoạch hoạt động cẩn thận và xem xét thường xuyên. Những cái này những thách thức tương tự như những thách thức liên quan đến việc thử nghiệm khả năng ứng phó với sự cố an ninh mạng khác khả năng [134], với nhu cầu tương tự để chống lại các vấn đề thường gặp như suy giảm cảnh giác [223]. Việc quản trị DON khác với nhiều hệ thống phi tập trung trong đó mức độ tiềm tàng của sự không đồng nhất. Mỗi DON có thể có các nguồn dữ liệu, tệp thực thi, yêu cầu cấp độ dịch vụ như thời gian hoạt động và người dùng riêng biệt. Mạng Chainlink Cơ chế quản trị phải đủ linh hoạt để thích ứng với những thay đổi trong mục tiêu và thông số hoạt động. Chúng tôi đang tích cực khám phá các ý tưởng thiết kế và lên kế hoạch công bố nghiên cứu về chủ đề này trong tương lai. 7,5 Cơ sở hạ tầng khóa công khai Với sự phân cấp tiến bộ sẽ xuất hiện nhu cầu xác định rõ ràng các những người tham gia mạng, bao gồm các nút DON. Đặc biệt, Chainlink yêu cầu mạnh mẽ Cơ sở hạ tầng khóa công khai (PKI). PKI là một hệ thống liên kết các khóa với danh tính. cho Ví dụ: PKI hỗ trợ hệ thống kết nối an toàn (TLS) của Internet: Khi bạn kết nối với một trang web qua HTTPS (ví dụ: https://www.chainlinklabs.com) và một lock xuất hiện trong trình duyệt của bạn, điều đó có nghĩa là khóa chung của chủ sở hữu tên miền có được cơ quan có thẩm quyền ràng buộc với chủ sở hữu đó—cụ thể là thông qua chữ ký số trong cái gọi là chứng chỉ. Một hệ thống phân cấp của các cơ quan cấp chứng chỉ (CA), có các cơ quan cấp cao nhất được cài đặt sẵn vào các trình duyệt phổ biến, giúp đảm bảo rằng các chứng chỉ chỉ được cấp cho chủ sở hữu hợp pháp của tên miền. Chúng tôi hy vọng rằng Chainlink cuối cùng sẽ sử dụng các dịch vụ tên phi tập trung, ban đầu là Ethereum Dịch vụ tên (ENS) [22], làm nền tảng cho PKI của chúng tôi. Như Tên của nó gợi ý, ENS tương tự như DNS, Hệ thống tên miền ánh xạ (người có thể đọc được) thành địa chỉ IP trên internet. Tuy nhiên, thay vào đó, ENS ánh xạ các tên Ethereum mà con người có thể đọc được tới các địa chỉ blockchain. Bởi vì ENS hoạt động trên Ethereum blockchain, ngăn chặn việc xâm phạm khóa, giả mạo khóa của nó không gian tên về nguyên tắc cũng khó như việc giả mạo hợp đồng quản lý nó và/hoặc blockchain cơ bản. (Ngược lại, DNS trước đây dễ bị tấn công để giả mạo, chiếm quyền điều khiển và các cuộc tấn công khác.) Chúng tôi đã đăng ký data.eth với ENS trên mạng chính Ethereum và dự định thiết lập nó như một không gian tên gốc, trong đó danh tính của các dịch vụ dữ liệu oracle và Chainlink thực thể mạng khác cư trú. Các miền trong ENS có tính phân cấp, nghĩa là mỗi miền có thể chứa các tham chiếu với các tên khác dưới nó. Tên miền phụ trong ENS có thể dùng như một cách để tổ chức vàủy thác sự tin tưởng. Vai trò chính của data.eth sẽ là phục vụ như một dịch vụ thư mục trên chuỗi cho nguồn cấp dữ liệu. Theo truyền thống, các nhà phát triển và người dùng oracle thường sử dụng các nguồn ngoài chuỗi (ví dụ: các trang web như docs.chain.link hoặc data.chain.link hoặc các mạng xã hội như Twitter) để xuất bản và lấy oracle địa chỉ nguồn cấp dữ liệu (chẳng hạn như giá ETH-USD thức ăn). Với không gian tên gốc có độ tin cậy cao như data.eth, thay vào đó, có thể thiết lập ánh xạ eth-usd.data.eth tới địa chỉ smart contract của công cụ tổng hợp mạng oracle trên chuỗi cho nguồn cấp dữ liệu giá ETH-USD. Điều này sẽ tạo đường dẫn an toàn để mọi người tham khảo blockchain làm nguồn thông tin chính xác cho nguồn cấp dữ liệu của cặp giá/tên đó (ETH-USD). Do đó, việc sử dụng ENS như vậy nhận ra hai lợi ích không có sẵn trong các nguồn dữ liệu ngoài chuỗi: • Bảo mật mạnh mẽ: Mọi thay đổi, cập nhật tên miền đều được ghi lại bất biến và được bảo mật bằng mật mã, trái ngược với địa chỉ văn bản trên một trang web, không được hưởng cả hai đặc tính bảo mật này. • Tuyên truyền tự động trên chuỗi: Cập nhật địa chỉ cơ bản của smart contract của nguồn cấp dữ liệu có thể kích hoạt thông báo truyền đến thông minh phụ thuộc hợp đồng và có thể, ví dụ, tự động cập nhật các hợp đồng phụ thuộc với các địa chỉ mới.13 Tuy nhiên, các không gian tên như ENS không tự động xác thực quyền sở hữu hợp pháp của những cái tên đã được khẳng định. Vì vậy, ví dụ, nếu không gian tên bao gồm mục ⟨“Acme Oracle Node Co.”, addr⟩, sau đó người dùng nhận được sự đảm bảo rằng addr thuộc về người yêu cầu tên Acme Oracle Node Co. Nếu không có cơ chế bổ sung về quản trị vùng tên, tuy nhiên, cô ấy không có được sự đảm bảo rằng tên đó thuộc về một thực thể một cách hợp pháp được gọi là Acme Oracle Node Co. theo nghĩa có ý nghĩa trong thế giới thực. Cách tiếp cận của chúng tôi để xác thực tên, tức là đảm bảo quyền sở hữu của chúng bởi các thực thể hợp pháp, tương ứng trong thế giới thực, dựa vào một số thành phần. Hôm nay, Chainlink Phòng thí nghiệm hoạt động hiệu quả như một CA cho mạng Chainlink. Trong khi Chainlink Lab sẽ tiếp tục để xác thực tên, PKI của chúng tôi sẽ phát triển thành một mô hình phi tập trung hơn theo hai cách: • Mô hình web-of-trust: Đối tác phi tập trung của PKI phân cấp thường được gọi là web-of-trust.14 Các biến thể đã được đề xuất từ những năm 1990, ví dụ: [98] và một số nhà nghiên cứu đã quan sát thấy rằng blockchain có thể tạo điều kiện thuận lợi cho việc sử dụng ý tưởng, ví dụ: [227] bằng cách ghi lại các chứng chỉ theo cách nhất quán trên toàn cầu sổ cái. Chúng tôi đang khám phá các biến thể của mô hình này để xác thực danh tính của các thực thể trong mạng Chainlink theo cách phi tập trung hơn. Hợp đồng phụ thuộc 13A có thể tùy chọn bao gồm thời gian trì hoãn được xác định trước để cho phép kiểm tra thủ công và sự can thiệp của các quản trị viên hợp đồng phụ thuộc. 14Thuật ngữ do Phil Zimmermann đặt ra cho PGP [238].• Liên kết với dữ liệu xác thực: Ngày nay, một lượng đáng kể dữ liệu hiệu suất nút oracle được hiển thị trên chuỗi và do đó được liên kết lưu trữ với các địa chỉ nút. Dữ liệu đó có thể được xem là làm phong phú thêm danh tính trong PKI bằng cách cung cấp bằng chứng lịch sử về sự tham gia (đáng tin cậy) của nó trong mạng. Ngoài ra, công cụ để nhận dạng phi tập trung dựa trên DECO và Town Crier [160] kích hoạt các nút để tích lũy thông tin xác thực có nguồn gốc từ dữ liệu trong thế giới thực. Chỉ là một ví dụ, một nhà điều hành nút có thể đính kèm thông tin xác thực vào danh tính PKI của nó để chứng minh quyền sở hữu theo xếp hạng của Dun và Bradstreet. Những hình thức xác nhận bổ sung này có thể bổ sung staking trong việc tạo sự đảm bảo an ninh mạng. Nút oracle có danh tính trong thế giới thực đã được thiết lập có thể được xem là có cổ phần trong một hệ thống xuất phát từ danh tiếng của nó. (Xem Phần 4.3 và Phần 9.6.3.) Yêu cầu cuối cùng đối với Chainlink PKI là khởi động an toàn, tức là an toàn xuất bản tên gốc cho mạng Chainlink, hiện tại là data.eth (tương tự nối cứng các tên miền cấp cao nhất trong trình duyệt). Nói cách khác, làm thế nào để Chainlink người dùng xác định rằng data.eth thực sự là miền cấp cao nhất được liên kết với Chainlink dự án? Giải pháp cho vấn đề này cho mạng Chainlink là đa hướng và có thể liên quan đến: • Thêm bản ghi TXT [224] vào bản ghi tên miền của chúng tôi cho chain.link chỉ định data.eth làm miền gốc cho hệ sinh thái Chainlink. (Chainlink do đó ngầm tận dụng PKI cho các miền internet để xác thực miền ENS gốc của nó.) • Liên kết tới data.eth từ trang web hiện tại của Chainlink, ví dụ: từ https://docs.chain.link. (Một cách sử dụng PKI ngầm khác cho các miền internet.) • Sử dụng data.eth được biết đến qua nhiều tài liệu khác nhau, bao gồm cả báo cáo chính thức này. • Đăng công khai data.eth trên các kênh truyền thông xã hội của chúng tôi, chẳng hạn như Twitter và blog Chainlink [18]. • Đặt một số lượng lớn LINK dưới sự kiểm soát của cùng một địa chỉ người đăng ký như data.eth.

信頼の最小化

異種のエンティティのセットが参加する分散型システムとして、 Chainlink ネットワークは、稼働性 (可用性) と安全性 (レポートの整合性) の両方において障害に対する強力な保護を提供します。ただし、ほとんどの分散システムにはさまざまな点があります。 構成コンポーネント自体が分散されている度合い。これ これは、マイナー間の分散化が限られている大規模システムであっても当てはまります [32] および 仲介者[51]は以前から存在していました。 分散化の取り組みの目標は、信頼を最小限に抑えることです。 Chainlink ネットワーク内のシステム的な破損や障害による悪影響。 悪意のあるDONが原因です。私たちの基本原則は、最小特権の原則 [197] です。 システムコンポーネントとシステム内のアクターには、厳密にスコープされた権限が必要です 割り当てられた役割を正常に完了することのみを許可します。 ここでは、Chainlink がドライブに採用する具体的なメカニズムをいくつか示します。 さらなる信頼の最小化に向けて。これらのメカニズムを次の観点から特徴づけます。 図 14 に示すように、遺伝子座、つまりそれらが根付いているシステムコンポーネントの位置を調べます。 各遺伝子座については、それぞれのサブセクションで説明します。 7.1 データソースの認証 oracle の現在の運用モデルは、データ ソースがほとんどないという事実によって制約されています。 TLS がネイティブに署名しないことが主な理由で、省略されたデータにデジタル署名します。 データ。 TLS は、「ハンドシェイク」プロトコルでデジタル署名を利用します（確立するため）。 サーバーとクライアント間の共有キー）。したがって、HTTPS 対応サーバーには証明書があります 原則としてデータの署名に使用できる公開鍵ですが、通常は使用されません。 これらの証明書はデータ署名をサポートします。したがって、DON のセキュリティは次のようになります。 今日のoracleネットワークでは、データからデータを忠実に中継するoracleノードに依存しています。 契約のソース。 Chainlink における信頼の最小化に関する当社のビジョンの重要な長期的な要素には、データ署名のためのツールと標準のサポートを通じた強力なデータ ソース認証が含まれます。データ署名は、エンドツーエンドの整合性保証を強制するのに役立ちます。 原則として、契約がデータの一部を入力として受け入れる場合、データによって直接署名された D

Loci of trust-minimizing mechanisms in the Chainlink network showing data quality, node selection, and oracle report verification

図 14: このセクションで説明する信頼最小化メカニズムの軌跡。 1⃝データ ソースは 2⃝DON にデータを提供し、データの機能を依存関係に中継します。 3⃝smart contract。 さらに、DON または oracle ネットワークには 4⃝ ノードが含まれます 補償ノード、ガードなどの MAINCHAIN 上の管理 smart contracts レールなど。 ソースがあれば、oracle ネットワークは D を改ざんすることはできません。 OpenID Connect など、このようなデータ署名を可能にする取り組みが現れています。 主にユーザー認証 [9]、TLS-N を目的とした学術プロジェクトのために設計されています。 TLS 証明書を再利用することで TLS [191] を拡張し、TLS 証拠拡張機能 [63] を使用します。 ただし、OpenID Connect はある程度の採用が見られますが、TLS Evidence Extensions は および TLS-N はまだ採用されていません。 データ ソース認証のもう 1 つの潜在的な手段は、発行者独自の認証を使用することです。 Signed HTTP Exchange (SXG) [230]。Accelerated Mobile Pages (AMP) プロトコル [225] の一部としてコンテンツ配信ネットワークにキャッシュできます。 Chrome モバイル ブラウザは、AMP でキャッシュされた SXG のコンテンツを、あたかも SXG から提供されているかのように表示します。 キャッシュ サーバー ドメインの代わりに、発行者自身のネットワーク ドメインを使用します。このブランド化のインセンティブは、CloudFlare の Real URL [83] や Google の amppackager [124] などのサービスを使用して有効にするのが比較的簡単であることと相まって、キャッシュされたニュース コンテンツでの SXG の広範な採用につながる可能性があります。 有効な SXG で報告されたニュース価値のあるイベントで Chainlink oracle がトリガーされる方法。 一方、ニュース出版社からの AMP キャッシュされた SXG はハイテンポには役に立ちません。 取引データに関するレポートなどのアプリケーションは、カスタム データの安全なソースとなる可能性があります。 異常気象や選挙結果などの現実世界の出来事に関連する契約。 私たちは、シンプルな導入、成熟したツール、および柔軟性が不可欠であると信じています。 データソース署名の高速化。データプロバイダーが Chainlink ノードを次のように使用できるようにする 認証された API フロントエンドは有望なアプローチであると思われます。私たちは、ネットワークへの参加の有無にかかわらず、ノードがこのモードで機能するためのオプション 本格的なoracleとして。この機能を認証済みデータ生成と呼びます。 (ADO)。 ADO で Chainlink ノードを使用すると、データ ソースは次の利点を得ることができます。 Chainlink コミュニティによって開発されたデジタル機能の追加の経験とツールから 既存のオフチェーン API スイートに署名機能を追加します。彼らは逃げることを選択すべきか ノードを oracle として使用すると、さらに潜在的な新しい収益源を開拓できます 既存のデータプロバイダーと同じモデルの下、例: Kraken [28]、Kaiko [140]、 その他、Chainlink ノードを実行して API データをチェーン上で販売するものもあります。 7.1.1 認証されたデータ生成の制限 データ ソースによるデジタル署名は、認証の強化には役立ちますが、それ自体では、oracle の本来のセキュリティや運用上の目標をすべて達成するには十分ではありません。 ネットワーク。 まず、特定のデータ D は堅牢かつタイムリーに中継される必要があります。 データ ソースから smart contract または他のデータ コンシューマーまでの経路。つまり、 依存関係に事前にプログラムされたキーを使用してすべてのデータが署名される理想的な設定 契約の場合でも、ソースからデータを確実に通信するには DON が必要になります。 契約書に。 さらに、契約書やその他のoracleデータが 消費者は、計算されたさまざまな関数の認証された出力へのアクセスを望んでいます。 ソース データには次の 2 つの主な理由があります。 • 機密性: データ ソース API は機密データまたは専有データを提供する場合があります。 チェーン上で公開される前に、編集またはサニタイズする必要があります。 ただし、署名されたデータを変更すると、署名が無効になります。もう一つ入れて ちなみに、単純な ADO とデータのサニタイズには互換性がありません。例 3 に示します ADO の強化された形式を通じて、この 2 つをどのように調整できるか。 • データ ソースの障害: エラーと障害の両方がデータ ソースに影響を与える可能性がありますが、デジタル署名はどちらの問題にも対処しません。 [98]、Chainlink は当初から このような障害を修復するメカニズム、つまり冗長性がすでに組み込まれています。 oracle ネットワークによって発行されるレポートは通常、複数のデータを組み合わせたものを表します。 ソース。 次に、ソース データの機密性を強化し、複数のソースからのデータを安全に結合するために、ADO 設定で検討しているスキームについて説明します。 7.1.2 機密保持 データ ソースは、必要な API の全範囲を予測して利用できるようにしていない可能性があります。 ユーザーによる。 具体的には、ユーザーは、事前に処理されたデータにアクセスして、 機密保持。次の例は、この問題を示しています。例 3. アリスは、次のような分散型アイデンティティ (DID) 資格情報を取得したいと考えています。 彼女が 18 歳以上であること (したがって、たとえばローンを組むことができる)。やること したがって、彼女は自分の年齢に関するこの事実を DID 資格情報発行者に証明する必要があります。 アリスは、自分の州の陸運局 (DMV) からのデータを使用したいと考えています。 という目的のためのウェブサイト。 DMV には彼女の生年月日の記録があり、 次の形式のデジタル署名された証明書 A: A = {名前: アリス、生年月日: 1999 年 2 月 16 日}。 この例では、アリスが DID に証明するには、証明書 A で十分である可能性があります。 資格情報の発行者は彼女が 18 歳以上であることを証明しました。しかし、機密情報が不必要に漏洩します: アリスの 正確なDoB。理想的には、アリスが代わりに DMV に求めているのは、 「アリスは 18 歳以上です」という単純なステートメント A'。言い換えれば、彼女が望んでいるのは、 彼女の誕生日 X に対する関数 G の出力。ここで、(非公式に) A' = G(X) = True の場合 現在の日付 -X ≥18 歳。それ以外の場合、G(X) = False。 一般的に言うと、アリスはデータ ソースから署名付きのデータをリクエストできるようにしたいと考えています。 形式の証明書 A': A' = {名前: アリス、機能: G(X)、結果: True}、 ここで、G(X) は関数 G とその入力 X の仕様を表します。 ユーザーは、要求の入力として希望する G(X) を提供できる必要があります。 対応する証明書 A'。 データ ソースの証明書 A' には、次の仕様 G(X) が含まれている必要があることに注意してください。 A' が正しく解釈されていることを確認します。上の例では、G(X) は次の意味を定義します。 A' のブール値の値、したがって True は証明の主題を意味します 18歳以上です。 ユーザーが G(X) を関数クエリとして指定できる柔軟なクエリを指します。 例 3 のようなユースケースやクエリを伴うユースケースをサポートするため 契約から直接、次のような機能クエリのサポートを含める予定です。 ADO の一部としての単純な関数 G。 7.1.3 ソースデータの結合 オンチェーンのコストを削減するために、契約は通常、結合されたデータを消費するように設計されています 次の例に示すように、複数のソースから。 例 4 (価格データの中央値化)。価格フィード、つまり 1 つの値を提供するため ある資産 (例: ETH) を別の資産 (例: USD) と比較すると、oracle ネットワークは通常、 取引所などの多くの情報源から現在の価格を取得します。 oracle ネットワーク 通常、これらの値の中央値を従属契約 SC に送信します。 データ署名のある環境では、正しく機能する oracle ネットワークは、 データ ソースから S = {S1, . 。 。 , SnS} 一連の値 V = {v1, v2, ... 。 。 、vnS}から ソース固有の署名を伴う nS ソース Σ = {σ1, σ2, ... 。 。 、σnS}。次第 署名を検証し、価格 v = median(V ) を SC に送信します。残念ながら、oracle ネットワークが中央値を送信する簡単な方法はありません。 例 4 の値 v を、v が正しく計算されたことの簡潔な証明 σ∗ とともに SC に送信します。 符号付き入力を超えます。 単純なアプローチは、すべての nS データ ソースの公開キーを SC でエンコードすることです。 oracle ネットワークは (V, Σ) を中継し、SC が V の中央値を計算できるようにします。 ただし、これでは証明 σ のサイズが O(nS) になります。つまり、σ∗ は簡潔ではありません。 また、SC ではすべての署名を検証する必要があるため、高額なガスコストが発生します。 Σ。 対照的に、SNARK を使用すると、正しく結合された認証されたソース値の簡潔な証明が可能になります。実際には実行可能かもしれないが、かなりの負担がかかる 証明者では計算コストがかかり、チェーンではガスのコストが若干高くなります。の使用 Town Crier も可能ですが、TEE の使用が必要であり、すべてに適しているわけではありません。 ユーザーの信頼モデル。 ソースから結合されたデータに署名するという一般的な問題に対する解決策を組み立てる有用な概念は、関数署名として知られる暗号化ツールです [59、132]。 簡単に言うと、機能署名を使用すると、署名者は次のような署名機能を委任できます。 デリゲート者は、署名者が選択した関数 F の範囲内のメッセージにのみ署名できます。 付録 D では、この機能的制約が範囲を制限するためにどのように機能するかを示します。 データ ソースによって署名された値の関数として DON によって出力されるレポート値。 また、離散化関数シグネチャと呼ばれる新しいプリミティブも導入します。これには、精度の要件が緩和されていますが、潜在的にはるかにパフォーマンスが向上します。 SNARKsなどのアプローチよりも。 ソース認証を含む方法でデータ ソースを結合する際の問題 出力の一部は、CoinCap、CoinMarketCap、CoinGecko などのデータ アグリゲーターにも適用されます。 CryptoCompare など、多数の取引所からデータを取得します。 場合によっては公開される方法論を使用して、体積に基づいた重み付けを行う 他の場合には独自のものになります。値を公開したいアグリゲータ ソース認証は、ノードの集合体を集約する場合と同じ課題に直面します。 ソースデータ。 7.1.4 ソースデータの処理 洗練された smart contract は、カスタム集計統計に依存する可能性があります。 多くの資産における最近の価格履歴のボラティリティなどの主要なデータ ソース、または 関連イベントに関するニュースのテキストと写真。 DON では計算と帯域幅が比較的安価であるため、これらの統計は— 多くの入力を持つ複雑な機械学習モデルであっても、blockchain に送られる出力値が十分に簡潔である限り、経済的に処理できます。 DON 参加者が異なる処理を行う可能性がある計算集約型ジョブの場合 複雑な入力に関する見解では、結果を計算する前に入力に関する合意を確立するために、DON 参加者間で追加のコミュニケーションが必要になる場合があります。 最終的な値が入力によって完全に決定される限り、入力のコンセンサスが確立されると、各参加者は単純に値を計算して他の参加者にブロードキャストできます。参加者に部分署名を付けるか、それをアグリゲーターに送信します。 7.2 DON 信頼の最小化 DON のコンポーネントに対する信頼を最小限に抑えるには、主に 2 つの方法を想定しています。 フェールオーバー クライアントとマイノリティ レポート。 7.2.1 フェイルオーバークライアント 暗号化および分散システムの文献における敵対的モデルは通常、 ノードのサブセットを破壊 (つまり侵害) できる敵を考えてみましょう。 たとえば、多くの BFT プロトコルでは 3 分の 1 未満です。一般的に観察されることですが、 すべてのノードが同一のソフトウェアを実行している場合、攻撃者が致命的なエクスプロイトを特定する可能性があります。 原則として、すべてのノードが多かれ少なかれ同時に侵害されます。この設定は多くの場合、 ソフトウェアモノカルチャー[47]と呼ばれます。 この問題に対処するために、ソフトウェアおよびソフトウェア構成を自動的に多様化するためのさまざまな提案が提出されている (例: [47, 113])。 [47] に記載されているように、 ただし、ソフトウェアの多様性は複雑な問題であり、慎重な検討が必要です。たとえば、ソフトウェアの多様化は、モノカルチャーよりもセキュリティが悪化する可能性があります。 システムの攻撃対象領域が増加し、その結果、可能性のある攻撃ベクトルが超過します。 セキュリティのメリットが得られます。 私たちは、堅牢なフェイルオーバー クライアント (つまり、どのノードに接続するクライアント) のサポートが重要であると考えています。 壊滅的な出来事に直面すると切り替えることができます。これは特に魅力的な形態です。 ソフトウェアの多様化。フェイルオーバークライアントは潜在的なベクトルの数を増加させません これらはメインライン ソフトウェアとして展開されていないため、攻撃の危険性が高まります。それらは明らかな利点を提供します。 ただし、第二の防衛線として。 DONs でフェイルオーバー クライアントをサポートする予定です。 これは、単一クライアントへのセキュリティへの依存を軽減するための重要な手段です。 Chainlink には、フェイルオーバー クライアントの堅牢なシステムがすでに導入されています。私たちのアプローチ これには、実戦テストされた以前のクライアント バージョンの維持が含まれます。たとえば、現在、オフチェーン レポート (OCR) をプライマリ クライアントとして使用する Chainlink ノードにはサポートが含まれています。 必要に応じて、Chainlink の以前の FluxMonitor システム用。ある程度使用されていたので FluxMonitor はセキュリティ監査とフィールド テストを受けています。同じものを提供します OCR としての機能を利用するには、コストがかかるだけです。コストは必要な場合にのみ発生します。 7.2.2 マイノリティ・レポート オマイノリティ (多数派による不正行為を観察する誠実なノードの一部) が十分に大きい少数派セットである場合、少数派を生成するのに役立つ可能性があります。 報告する。これは並行レポートまたはフラグであり、オンチェーンの従属契約 SC に中継されます。 オマイノリティによる。 SC は、独自の契約固有のポリシーに従ってこのフラグを使用できます。 たとえば、生存性や応答性よりも安全性が重要である契約の場合、少数派の報告により、契約は補足報告を要求する可能性があります。 別の DON から接続するか、サーキット ブレーカーをトリガーします (次のセクションを参照)。たとえ大多数が正直であっても、少数派の報告は重要な役割を果たすことができます。 なぜなら、レポート集計スキームは、機能的シグネチャを使用する場合でも、 oracle またはデータ障害に対する回復力を確保するために、しきい値方式で動作します。で 言い換えれば、次の入力に基づいて有効なレポートを作成できなければなりません。 kS < nS oracles、あるしきい値 kS の場合。 これは、破損した DON には、 優先 kS 値を選択することにより、レポート値を操作する自由度が高くなります。 すべてのソースが正直である場合でも、V では oracle の完全なセットによって nS が報告されます。 たとえば、関数型を使用するシステムで nS = 10 および kS = 7 であると仮定します。 ETH の USD 価格の V に対する中央値の計算を認証するための署名。 5 つの情報源が \(500, while the other five report \)1000 の価格を報告しているとします。 次に、下位 7 つのレポートを中央値化することにより、DON は有効な値 v = $500 を出力できます。 そして最高値を中央値化すると、v = $1000 が出力されます。 DON プロトコルを強化して、すべてのノードがどのデータがあったかを認識できるようにする 利用可能なデータ、およびレポートの作成に使用されたデータをノードが検出してフラグを立てることができます。 あるセットのレポートを別のセットのレポートよりも好むという統計的に有意な傾向があり、 結果として少数派の報告書となる。 7.3 ガードレール DONs の信頼モデルは、MAINCHAIN をより高いセキュリティとより高い特権として扱います。 DONs よりもシステムが優れています。 (この信頼モデルは必ずしも当てはまらないかもしれませんが、より簡単です DON の方がセキュリティが高い状況に結果のメカニズムを適応させるため プラットフォームはその逆です)。 したがって、自然な信頼最小化戦略には、smart contracts (MAINCHAIN フロントエンドのいずれか) での監視およびフェイルセーフ メカニズムの実装が含まれます。 DON の場合、または従属契約 SC 内で直接。これらのメカニズムを次のように呼びます。 ガードレール、そして最も重要なものをここにいくつか列挙します。 • サーキットブレーカー: SC は、状態更新自体の特性 (例: シーケンシャル間の大きな差異など) のいずれかの関数として、状態更新を一時停止または停止することがあります。 レポート）、または他の入力に基づいて。たとえば、サーキットブレーカーが落ちる可能性があります。 oracle レポートが時間の経過とともに信じられないほど変化する場合。サーキットブレーカーが作動する可能性があります マイノリティレポートにもつまずかれる。したがって、サーキットブレーカーはDONを防ぐことができます 著しく誤った報告をしないこと。 サーキットブレーカーは、追加の介入を検討するための時間を提供することができます または運動した。そのような介入の 1 つは避難ハッチです。 • 避難用ハッチ: 管理者、コミュニティ token 保持者、またはその他の受託者団体によって特定された不利な状況下では、契約によって以下の措置が講じられる場合があります。 緊急設備は避難ハッチ [163] とも呼ばれます。脱出ハッチ SC を何らかの方法でシャットダウンしたり、保留中の終了を引き起こしたり、場合によっては 今後の取引。たとえば、保管されている資金をユーザーに返還する場合があります ([17])、契約条件 [162] を終了するか、保留中の取引および/または今後の取引 [173] をキャンセルする場合があります。避難ハッチは、あらゆるタイプの契約に導入できます。 DON に依存するものですが、それらは潜在的なバッファーとして興味深いものです。 DON 不正行為。 • フェイルオーバー: SC が重要なサービスについて DON に依存しているシステムでは、SC がフェイルオーバー メカニズムを提供して、たとえ DON の失敗または不正行為の場合。たとえば、TEF (セクション 6) では、次のようになります。 アンカー コントラクト SCa は、オンチェーンと オフチェーン実行インターフェイスは、特定の重要な操作 (例: 引き出し）、または通常のトランザクションの場合は、DON トランザクションのフロントランニングを防ぐために適切な遅延が発生します。データ ソースがデータに署名する場合、ユーザーは DON が失敗した場合にも、SCa に報告書を提出します。 さまざまな形式の楽観的 rollup に対して提案されている不正証明 (セクション 6.3 を参照)、 風味が似ており、上で列挙したメカニズムを補完します。彼らは また、オンチェーン監視の形式と潜在的な障害に対する保護も提供します。 オフチェーン システム コンポーネント。 7.4 信頼を最小限に抑えたガバナンス すべての分散システムと同様、Chainlink ネットワークにはガバナンス メカニズムが必要です 時間の経過とともにパラメータを調整し、緊急事態に対応し、その進化を導きます。 これらのメカニズムの一部は現在 MAINCHAIN 上に存在しており、今後も存続する可能性があります。 DONs の展開でもそうしてください。一例として、支払いメカニズムが挙げられます。 oracle ノード プロバイダー (DON ノード) の場合。 DON MAINCHAIN 上のフロントエンド コントラクト ガードレールなどの追加の機構が含まれており、定期的な規制を受ける可能性があります。 改造。 私たちは、進化型と緊急型という 2 つの種類のガバナンス メカニズムを予測しています。 進化的ガバナンス: Chainlink エコシステムに対する多くの変更は、 実装が緊急の問題ではないようにします: パフォーマンスの向上、 機能強化、（緊急ではない）セキュリティ アップグレードなど。 Chainlink はガバナンスへの参加者をさらに増やす方向に徐々に移行しており、多くの参加者や参加者が増えることが予想されます。 このような変更のほとんどは、影響を受ける特定の DON のコミュニティによって承認される必要があります。 変化します。暫定的に、そしておそらく最終的には並行メカニズムとして、私たちは次のように信じています。 一時的な最小特権の概念は、進化的ガバナンスを実装する有用な手段となり得るということです。非常に簡単に言うと、変更を段階的に展開して、 コミュニティは彼らに応える機会です。たとえば、新しいものへの移行 MAINCHAIN コントラクトは、新しいコントラクトをデプロイする必要があるように制約することができます 有効化の少なくとも 30 日前までに。緊急時のガバナンス: MAINCHAIN の悪用可能な脆弱性または悪用された脆弱性 契約やその他の形式の生存性または安全性の欠陥では、壊滅的な結果を防ぐために即時介入が必要になる場合があります。私たちの目的はマルチシグをサポートすることです あらゆる組織による不正行為を確実に防止するための介入メカニズム。 署名者は組織全体に分散されます。署名者の一貫した可用性を確保する 緊急事態の許可のための適切な指揮系統へのタイムリーなアクセス 変更には、慎重な運用計画と定期的なレビューが必要であることは明らかです。これら 課題は、他のサイバーセキュリティ インシデント対応のテストに伴う課題と似ています。 能力 [134] は、警戒力の低下 [223] などの一般的な問題に対処するための同様の必要性を伴います。 DON のガバナンスは、多くの分散システムのガバナンスとは異なります。 潜在的な異質性の程度。各 DON には、個別のデータ ソース、実行可能ファイル、稼働時間などのサービス レベル要件、ユーザーが含まれる場合があります。 Chainlink ネットワークの ガバナンスメカニズムは、そのような変化に対応できる十分な柔軟性を備えていなければなりません。 運用上の目標とパラメータ。私たちはデザインのアイデアを積極的に検討しており、次のことを計画しています。 将来的にはこのテーマに関する研究を発表する予定です。 7.5 公開鍵インフラストラクチャ 分散化が進むにつれて、 DON ノードを含むネットワーク参加者。特に、Chainlink には強力な 公開鍵インフラストラクチャー (PKI)。 PKI は、キーを ID にバインドするシステムです。のために たとえば、PKI はインターネットの安全な接続 (TLS) システムを支えています。 HTTPS (例: https://www.chainlinklabs.com) を介して Web サイトに接続し、 ブラウザにロックが表示されます。これは、ドメイン所有者の公開キーが 権限によって、具体的にはデジタル署名を通じてその所有者に結び付けられています。 いわゆる証明書。認証局 (CA) の階層システムは、そのトップレベルのルート認証局が一般的なブラウザに組み込まれており、証明書の確実な発行に役立ちます。 ドメインの正当な所有者にのみ発行されます。 Chainlink は最終的には分散型ネーム サービスを利用することになると予想しています。 最初は、PKI の基盤として、Ethereum ネーム サービス (ENS) [22] を使用しました。として その名前が示すように、ENS は DNS (マッピングを行うドメイン ネーム システム) に似ています。 (人間が読める) ドメイン名をインターネット上の IP アドレスに変換します。ただし、ENS は代わりに、人間が判読できる Ethereum 名を blockchain アドレスにマッピングします。 ENSだから Ethereum blockchain 上で動作し、鍵の侵害や改ざんがない限り、 名前空間は原則として、それを管理する契約を改ざんするのと同じくらい難しい および/または基礎となるblockchain。 (対照的に、DNS は歴史的に脆弱でした) スプーフィング、ハイジャック、その他の攻撃から保護します。) 私たちは data.eth を Ethereum メインネット上の ENS に登録しており、 これをルート名前空間として確立し、その下に oracle データ サービスの ID と 他の Chainlink ネットワーク エンティティが存在します。 ENS のドメインは階層構造になっており、各ドメインに参照が含まれる可能性があります。 その下の他の名前に。 ENS のサブドメインは、組織化および委任の信頼。 data.eth の主な役割は、オンチェーン ディレクトリ サービスとして機能することです。 データフィード。従来、oracles の開発者とユーザーはオフチェーン ソースを使用してきました。 (例: docs.chain.link や data.chain.link などの Web サイト、または次のようなソーシャル ネットワーク Twitter) oracle データ フィード アドレス (ETH-USD 価格など) を公開および取得する フィード）。 data.eth などの信頼性の高いルート名前空間を使用すると、代わりに、smart contract アドレスなどへの eth-usd.data.eth のマッピングを確立することができます。 ETH-USD 価格フィード用のオンチェーン oracle ネットワーク アグリゲーターの。これは 誰もがblockchainを信頼できる情報源として参照できる安全なパスを作成します。 その価格/名前ペア (ETH-USD) のデータ フィード。したがって、ENS のそのような使用は、 オフチェーン データ ソースでは利用できない 2 つの利点を実現します。 • 強力なセキュリティ: ドメインに対するすべての変更と更新は不変に記録されます。 Web サイト上のテキスト アドレスとは対照的に、暗号化によって保護されています。 これら 2 つのセキュリティ特性のどちらも享受できません。 • 自動化されたオンチェーン伝播: データフィードの smart contract の基礎となるアドレスを更新すると、依存するスマートに伝播する通知をトリガーできます。 契約を作成し、たとえば、依存する契約を自動的に更新できます。 新しいアドレス.13 ただし、ENS のような名前空間は、正当な所有権を自動的に検証しません。 アサートされた名前の。したがって、たとえば、名前空間に次のエントリが含まれている場合、 ⟨「Acme Oracle Node Co.」、addr⟩、 そうすれば、ユーザーは、addr が Acme という名前の主張者に属しているという保証を得ることができます。 Oracle Node Co. ネームスペース管理に関する追加のメカニズムがなければ、 ただし、その名前が合法的に実体に属しているという保証は得られていません。 現実世界では意味のある意味で Acme Oracle Node Co. と呼ばれます。 名前の検証に対する私たちのアプローチ、つまり、対応する正当な現実世界のエンティティによる名前の所有権の確保は、いくつかのコンポーネントに依存しています。今日、Chainlink 研究室 Chainlink ネットワークの CA として効果的に機能します。 Chainlink ラボは継続します 名前を検証するために、PKI は次の 2 つの方法でより分散化されたモデルに進化します。 • Web-of-trust モデル: 階層型 PKI の分散型モデルは、多くの場合、web-of-trust と呼ばれます。14 バリアントは 1990 年代から提案されてきました。 例: [98]、そして多くの研究者は、blockchain が世界的に一貫した形式で証明書を記録することによって、アイデア (例: [227]) の使用を容易にすることができることを観察しています。 台帳。私たちは、エンティティの身元を検証するために、このモデルのバリアントを調査しています。 Chainlink ネットワーク内でより分散化された方法で。 13A 従属契約には、手動検査を可能にするための所定の遅延をオプションで含めることができます。 および従属契約管理者による介入。 14Phil Zimmermann が PGP [238] のために作った用語。• 検証データへのリンク: 現在、かなりの量の oracle ノード パフォーマンス データがチェーン上で表示され、アーカイブ的にノード アドレスにバインドされています。 このようなデータは、ネットワークへの (信頼できる) 参加の歴史的証拠を提供することによって、PKI のアイデンティティを強化すると見なすことができます。さらに、ツール DECO および Town Crier [160] に基づく分散型アイデンティティのノードの有効化 実世界のデータから得られた認証情報を蓄積します。ほんの一例として、 ノードオペレーターは、所有を証明する資格情報をその PKI ID に添付できます。 ダンとブラッドストリートの評価の。これらの補足的な検証形式では、 ネットワークのセキュリティを保証するために、staking を補足してください。現実世界のアイデンティティが確立されている oracle ノードは、ステークを持っているとみなされる場合があります その評判に基づいたシステムで。 (セクション 4.3 およびセクション 9.6.3 を参照してください。) Chainlink PKI の最後の要件は、安全なブートストラップです。 Chainlink ネットワークのルート名 (現在は data.eth) を公開します (同様に ブラウザのトップレベル ドメインのハードワイヤードに）。言い換えれば、Chainlink ユーザーはどうやって data.eth が実際に Chainlink に関連付けられたトップレベル ドメインであることを確認します。 プロジェクト？ Chainlink ネットワークのこの問題に対する解決策は多面的であり、 以下が含まれる可能性があります: • を指定する TXT レコード [224] をchain.link のドメイン レコードに追加します。 data.eth を Chainlink エコシステムのルート ドメインとして使用します。 (Chainlink は、インターネット ドメインの PKI を暗黙的に利用して、ルート ENS ドメインを検証します。) • Chainlink の既存の Web サイトから data.eth にリンクする（例: https://docs.chain.link. (インターネット ドメインに対する PKI のもう 1 つの暗黙的な使用。) • このホワイトペーパーを含むさまざまな文書を通じて data.eth の利用を周知する。 • Twitter などの当社のソーシャル メディア チャネルに data.eth を公に投稿する。 Chainlink ブログ [18]。 • 大量の LINK を同じ登録者アドレスの管理下に置くこと data.ethとして。

DON Cân nhắc triển khai

Mặc dù không phải là một phần trong thiết kế cốt lõi của chúng tôi nhưng có một số cân nhắc kỹ thuật quan trọng trong việc nhận ra DON đáng được điều trị ở đây.

8.1 Phương pháp triển khai Bài viết này đưa ra một tầm nhìn đầy tham vọng về chức năng Chainlink nâng cao mà Việc hiện thực hóa sẽ đòi hỏi các giải pháp cho nhiều thách thức trên đường đi. Sách trắng này xác định một số thách thức, nhưng những thách thức không lường trước được chắc chắn sẽ phát sinh. Chúng tôi dự định triển khai các yếu tố của tầm nhìn này theo cách tăng dần theo thời gian. khoảng thời gian kéo dài. Kỳ vọng của chúng tôi là DON ban đầu sẽ khởi chạy với hỗ trợ cho các thành phần dựng sẵn cụ thể được các nhóm trong nhóm hợp tác xây dựng Chainlink cộng đồng. Mục đích là sử dụng DONs rộng rãi hơn, ví dụ: khả năng khởi chạy các tệp thực thi tùy ý, sẽ thấy hỗ trợ sau. Một lý do cần thận trọng như vậy là thành phần của smart contract có thể có những tác dụng phụ phức tạp, ngoài ý muốn và nguy hiểm, như các cuộc tấn công dựa trên khoản vay nhanh gần đây đã gây ra ví dụ được hiển thị [127, 189]. Tương tự, thành phần của smart contract, bộ điều hợp và các tệp thực thi sẽ yêu cầu hết sức cẩn thận. Trong quá trình triển khai DON ban đầu, chúng tôi dự định chỉ bao gồm một tập hợp các bộ điều hợp và thực thi được tạo khuôn mẫu dựng sẵn. Điều này sẽ cho phép nghiên cứu về an ninh thành phần của các chức năng này bằng cách sử dụng các phương pháp hình thức [46, 170] và các cách tiếp cận khác. Nó sẽ cũng đơn giản hóa việc định giá: Việc định giá chức năng có thể được thiết lập bởi các nút DON trên cơ sở chức năng, thay vì thông qua đo lường tổng quát, một cách tiếp cận được áp dụng trong, ví dụ: [156]. Chúng tôi cũng mong muốn cộng đồng Chainlink tham gia vào quá trình tạo các mẫu bổ sung, kết hợp nhiều bộ điều hợp và tệp thực thi khác nhau để ngày càng các dịch vụ phi tập trung hữu ích có thể được điều hành bởi hàng trăm, nếu không phải hàng nghìn cá nhân DONs. Ngoài ra, cách tiếp cận này có thể giúp ngăn ngừa sự phình to của trạng thái, tức là nhu cầu DON các nút để giữ lại một lượng trạng thái không thể thực hiện được trong bộ nhớ làm việc. Vấn đề này là đã phát sinh trong blockchains không được phép, thúc đẩy các phương pháp tiếp cận như “không quốc tịch khách hàng” (xem ví dụ: [206]). Nó có thể gay gắt hơn trong các hệ thống thông lượng cao hơn, thúc đẩy một cách tiếp cận trong đó DON chỉ triển khai các tệp thực thi được tối ưu hóa theo quy mô trạng thái. Khi DON phát triển và hoàn thiện, đồng thời bao gồm các rào chắn bảo vệ mạnh mẽ, như được thảo luận trong Phần 7, các cơ chế bảo mật dựa trên danh tiếng và kinh tế tiền điện tử như được thảo luận trong Phần 9, cũng như các tính năng khác cung cấp mức độ đảm bảo cao cho người dùng DON, chúng tôi cũng mong muốn phát triển một khuôn khổ và các công cụ để tạo điều kiện cho việc triển khai và sử dụng rộng rãi hơn DON bởi cộng đồng. Lý tưởng nhất là những công cụ này sẽ cho phép một tập hợp các toán tử nút kết hợp với nhau thành một mạng oracle và khởi chạy DON của riêng họ theo cách không cần cấp phép hoặc theo cách tự phục vụ, nghĩa là họ có thể đơn phương thực hiện việc đó. 8.2 Năng động DON Tư cách thành viên Tập hợp các nút chạy DON nhất định có thể thay đổi theo thời gian. Có hai cách tiếp cận quản lý khóa cho skL với tư cách thành viên năng động trong O. Đầu tiên là cập nhật phần chia sẻ của skL do các nút nắm giữ khi có thay đổi về tư cách thành viên, trong khi vẫn giữ pkL không thay đổi. Cách tiếp cận này, được khám phá trong [41, 161, 198], có giá trị không yêu cầu các bên liên quan cập nhật pkL.Kỹ thuật chia sẻ lại chia sẻ cổ điển, được giới thiệu trong [122], cung cấp một cách đơn giản và cách hiệu quả để hiện thực hóa các cập nhật chia sẻ đó. Nó cho phép một bí mật được chuyển giao giữa một tập hợp các nút O(1) và một giây, có thể giao nhau với một O(2). Trong này cách tiếp cận, mỗi nút O(1) tôi thực hiện (k(2), n(2)) chia sẻ bí mật việc chia sẻ bí mật của nó trên các nút trong O(2) với n(2) = |O(2)| và ngưỡng mong muốn (có thể là mới) k(2). Các sơ đồ chia sẻ bí mật có thể xác minh (VSS) khác nhau [108] có thể cung cấp bảo mật chống lại kẻ thù chủ động làm hỏng các nút, tức là đưa hành vi nguy hiểm vào giao thức. Các kỹ thuật trong [161] nhằm mục đích thực hiện điều đó đồng thời giảm độ phức tạp trong giao tiếp và cung cấp khả năng phục hồi chống lại các thất bại trong các giả định về độ cứng của mật mã. Cách tiếp cận thứ hai là cập nhật khóa sổ cái pkL. Điều này có lợi ích về phía trước bảo mật: Việc thỏa hiệp các cổ phiếu cũ của pkL (tức là các nút ủy ban cũ) sẽ không dẫn đến sự thỏa hiệp của khóa hiện tại. Tuy nhiên, các bản cập nhật lên pkL có hai nhược điểm: (1) Dữ liệu được mã hóa theo pkL cần được mã hóa lại trong quá trình làm mới khóa và (2) Các cập nhật quan trọng cần được phổ biến tới các bên tin cậy. Chúng tôi dự định khám phá cả hai cách tiếp cận cũng như sự kết hợp của cả hai. 8.3 DON Trách nhiệm Giống như các mạng Chainlink oracle hiện có, DON sẽ bao gồm các cơ chế về trách nhiệm giải trình, tức là ghi lại, giám sát và thực thi hành vi chính xác của nút. DONs sẽ có dung lượng dữ liệu đáng kể hơn nhiều so với nhiều blockchain không được phép hiện có, đặc biệt là khả năng kết nối với bộ lưu trữ phi tập trung bên ngoài. Do đó, họ sẽ có thể ghi lại lịch sử hiệu suất của các nút một cách chi tiết, cho phép cơ chế trách nhiệm giải trình chi tiết hơn. Ví dụ: tính toán ngoài chuỗi của giá tài sản có thể liên quan đến các yếu tố đầu vào bị loại bỏ trước khi kết quả trung bình được gửi đi chuỗi. Trong DON, những kết quả trung gian này có thể được ghi lại. Do đó, hành vi sai trái hoặc mất hiệu suất của các nút riêng lẻ trong DON có thể được khắc phục hoặc bị phạt đối với DON một cách chi tiết. Chúng tôi cũng đã thảo luận thêm về các phương pháp xây dựng lan can bảo vệ trong Phần 7.3 đề cập đến tác động cụ thể theo hợp đồng của các lỗi hệ thống. Tuy nhiên, điều quan trọng là phải có cơ chế an toàn cho chính DON, tức là, các biện pháp bảo vệ chống lại các lỗi hệ thống, có khả năng gây thảm họa DON, cụ thể là các lỗi phân nhánh/không rõ ràng và thỏa thuận cấp độ dịch vụ (SLA), như chúng tôi giải thích hiện nay. Phân nhánh/không rõ ràng: Với đủ nhiều nút bị lỗi, DON có thể phân nhánh hoặc lập lờ, tạo ra hai khối hoặc chuỗi khối riêng biệt, không nhất quán trong L. Tuy nhiên, vì DON ký điện tử vào nội dung của L nên có thể tận dụng chuỗi chính MAINCHAIN để ngăn chặn và/hoặc trừng phạt hành vi không rõ ràng. DON có thể kiểm tra định kỳ trạng thái điểm từ L trong hợp đồng kiểm tra trên MAINCHAIN. Nếu trạng thái trong tương lai của nó khác với trạng thái được kiểm tra, người dùng/kiểm toán viên có thể đưa ra bằng chứng về hành vi sai trái này đối với hợp đồng kiểm toán. Bằng chứng như vậy có thể được sử dụng để tạo ra một cảnh báo hoặc phạt DON nút bằng cách gạch chéo trong hợp đồng. Cách tiếp cận sau này giới thiệu một vấn đề thiết kế khuyến khích tương tự như vấn đề đối với các nguồn cấp dữ liệu oracle cụ thể và có thể xây dựng dựa trên công việc của chúng tôi được nêu trong Phần 9.Thực thi các thỏa thuận cấp độ dịch vụ: Mặc dù DON không nhất thiết nhằm mục đích chạy vô thời hạn, điều quan trọng là chúng phải tuân thủ các thỏa thuận cấp độ dịch vụ (SLA) với người dùng của họ. Có thể thực thi SLA cơ bản trên chuỗi chính. Ví dụ, Các nút DON có thể cam kết duy trì DON cho đến một ngày nhất định hoặc cung cấp thông báo trước về việc chấm dứt dịch vụ (ví dụ: thông báo trước ba tháng). Một hợp đồng trên MAINCHAIN có thể cung cấp việc thực thi SLA kinh tế tiền điện tử cơ bản. Ví dụ: hợp đồng SLA có thể cắt giảm số tiền ký gửi DON nếu điểm kiểm tra không được cung cấp ở những khoảng thời gian cần thiết. Người dùng có thể gửi tiền và thách thức DON để chứng minh rằng điểm kiểm tra thể hiện chính xác một chuỗi các khối hợp lệ (theo cách tương tự như, ví dụ: [141]). Tất nhiên, sản xuất khối không đồng nghĩa với giao dịch. xử lý, nhưng hợp đồng SLA cũng có thể dùng để thực thi quy trình sau. Ví dụ, trong phiên bản tương thích cũ của FSS trong đó các giao dịch được tìm nạp từ mempool (xem Phần 5.2), các giao dịch cuối cùng sẽ được khai thác và đặt trên chuỗi. Một người dùng có thể chứng minh DON hành vi sai trái bằng cách cung cấp cho hợp đồng SLA một giao dịch đã được khai thác nhưng không được DON truyền đi để hợp đồng mục tiêu xử lý trong khoảng thời gian thích hợp.15 Cũng có thể chứng minh sự tồn tại và xử phạt SLA chi tiết hơn các lỗi, bao gồm các lỗi trong tính toán sử dụng các tệp thực thi (ví dụ: thông qua các cơ chế để chứng minh các giao dịch trạng thái ngoài chuỗi chính xác được nêu trong Phần 6.3) hoặc không chạy được các tệp thực thi dựa trên các trình khởi tạo hiển thị trên DON, không thể chuyển tiếp dữ liệu trên DON tới MAINCHAIN một cách kịp thời, v.v.

DON 導入に関する考慮事項

私たちのコア設計の一部ではありませんが、いくつかの重要な技術的考慮事項があります。 ここでの治療に値するDONの実現において。

8.1 ロールアウトアプローチ この文書では、高度な Chainlink 機能の野心的なビジョンを示します。 実現には、その過程で多くの課題を解決する必要があります。このホワイトペーパー いくつかの課題を特定しましたが、予期せぬ課題が必ず発生します。 私たちは、このビジョンの要素を段階的に実装する予定です。 延長された期間。 私たちの予想では、DONs は最初に次のように起動されることになります。 社内のチームが協力して構築した特定の事前構築コンポーネントのサポート Chainlink コミュニティ。その目的は、DONs をより広範に使用できるようにすることです。 任意の実行可能ファイルを起動します。後でサポートされる予定です。 このような注意が必要な理由の 1 つは、最近のフラッシュ ローン ベースの攻撃のように、smart contract の構成には複雑で意図しない危険な副作用が生じる可能性があるためです。 たとえば[127、189]に示されています。同様に、smart contract、アダプター、および 実行可能ファイルには細心の注意が必要です。 DONs の最初の展開では、テンプレート化された実行可能ファイルとアダプターの事前構築済みセットのみを含める予定です。これにより、構成的安全性の研究が可能になります。 形式的な手法 [46、170] やその他のアプローチを使用して、これらの機能を解析します。そうなります また、価格設定も簡素化します。機能の価格設定は、一般化されたメータリングではなく、機能ごとに基づいて DON ノードによって確立できます。このアプローチは採用されています。 例: [156]。また、Chainlink コミュニティが作成に参加することも期待しています。 追加のテンプレートを使用して、さまざまなアダプターと実行可能ファイルを組み合わせて、 数千ではないにしても、数百の個人によって実行できる便利な分散型サービス DON秒。 さらに、このアプローチは、状態の肥大化、つまり DON の必要性を防ぐのに役立ちます。 ノードを使用して、作業不可能な量の状態を作業メモリに保持します。この問題は パーミッションレス blockchain ではすでに発生しており、「ステートレス」などのアプローチが動機付けられています。 クライアント」（[206] などを参照）。高スループットのシステムではより深刻になる可能性があり、モチベーションが高まります。 DON が状態サイズに最適化された実行可能ファイルのみをデプロイするアプローチ。 DON が進化し成熟し、セクション 7 で説明した堅牢なガード レール、セクション 9 で説明した暗号経済およびレピュテーション ベースのセキュリティ メカニズム、および DON ユーザーに高度な保証を提供するその他の機能が組み込まれるにつれて、私たちは また、より広範な立ち上げと使用を促進するためのフレームワークとツールを開発することも期待されています。 コミュニティによるDONs。理想的には、これらのツールによりノード オペレーターのコレクションが可能になります。 oracle ネットワークとして統合し、パーミッションレスで独自の DON を起動します。 またはセルフサービス方式、つまり一方的に行うことができます。 8.2 動的 DON メンバーシップ 特定の DON を実行するノードのセットは、時間の経過とともに変化する可能性があります。 2つのアプローチがあります O の動的メンバーシップが与えられた skL の鍵管理に。 1 つ目は、メンバーシップの変更時にノードが保持する skL のシェアを更新することです。 pkL を変更しないままにします。 [41、161、198] で検討されているこのアプローチには利点があります。 証明書利用者が pkL を更新することを要求しないこと。[122] で導入された共有再共有の古典的な手法は、簡単な機能を提供します。 そしてそのような共有の更新を実現する効率的な方法。シークレットの転送が可能になります 1 つのノードのセット O(1) と、おそらく交差する 1 つのノード O(2) との間。この中で アプローチ、各ノード O(1) 私は 秘密共有の (k(2), n(2)) 秘密共有を実行します。 n(2) = |O(2)| の O(2) 内のノードおよび望ましい（おそらく新しい）閾値 k(2)。さまざまな検証可能な秘密共有 (VSS) スキーム [108] は、次のような敵に対してセキュリティを提供できます。 ノードを積極的に破壊します。つまり、プロトコルに悪意のある動作を導入します。 [161] の技術は、通信の複雑さを軽減し、提供することを目的としています。 暗号強度の仮定における失敗に対する回復力。 2 番目のアプローチは、レジャーキー pkL を更新することです。これには前進する利点があります セキュリティ: pkL の古い共有 (つまり、以前の委員会ノード) が侵害されることはありません 現在のキーが侵害される可能性があります。ただし、pkL のアップデートには 2 つの欠点があります。 (1) pkL で暗号化されたデータはキー更新時に再暗号化する必要がある、および (2) 主要な更新は信頼当事者に伝播する必要があります。 私たちは両方のアプローチと、その 2 つのハイブリッド化を検討するつもりです。 8.3 DON 説明責任 既存の Chainlink oracle ネットワークと同様に、DONs には、正しいノード動作の記録、監視、強制などの説明責任のメカニズムが含まれます。 DON は 既存の多くの許可のない blockchain よりもはるかに大きなデータ容量、 特に外部の分散ストレージに接続できる機能を考慮すると、その結果、ノードのパフォーマンス履歴を詳細に記録できるようになり、 よりきめの細かい説明責任メカニズム。たとえば、次のオフチェーン計算 資産価格には、中央値の結果が送信される前に破棄される入力が含まれる場合があります。 チェーン。 DON には、これらの中間結果を記録できます。したがって、DON 内の個々のノードによる不正な動作やパフォーマンスの低下は、修正またはペナルティを受ける可能性があります。 DON をきめ細かい方法で確認します。構築するためのアプローチについても説明しました。 システム障害による契約固有の影響に対処するセクション 7.3 のガード レール。 ただし、DON 自体にフェイルセーフ メカニズムを設けることも重要です。 具体的には、システム全体の、潜在的に壊滅的なDON障害に対する保護です。 これから説明するように、フォーク / あいまいさおよびサービス レベル アグリーメント (SLA) の失敗について説明します。 分岐/曖昧さ: 障害のあるノードが十分に多い場合、DON はフォークする可能性があります または曖昧で、L 内に 2 つの別個の矛盾したブロックまたはブロックのシーケンスが生成されます。 ただし、DON は L の内容にデジタル署名するため、 メインチェーン MAINCHAIN を使用して、あいまいな表現を防止および/またはペナルティを課します。 DON は、MAINCHAIN 上の監査コントラクト内の L からの状態を定期的にチェックポイントできます。 将来の状態がチェックポイント設定された状態から逸脱した場合、ユーザー/監査人は証拠を提示できます。 この不正行為を監査契約に反映させます。このような証拠は、アラートを生成するために使用できます。 または、コントラクト内のスラッシュによって DON ノードにペナルティを課します。後者のアプローチでは、次のようなことが起こります。 特定の oracle フィードの場合と同様のインセンティブ設計の問題であり、それに基づいて構築することができます 私たちの取り組みについてはセクション 9 で概説します。サービスレベル契約の強制: DON は必ずしも次のことを意図しているわけではありませんが、 無期限に実行されるため、サービス レベル アグリーメント (SLA) に準拠することが重要です ユーザーとともに。基本的な SLA の適用はメイン チェーンで可能です。たとえば、 DON ノードは、特定の日付まで DON を維持すること、またはサービス終了の事前通知 (例: 3 か月前の通知) を提供することを約束する場合があります。に関する契約 MAINCHAIN は、基本的な暗号経済 SLA 強制を提供できます。 たとえば、チェックポイントが設定されている場合、SLA 契約では DON が預け入れた資金を削減できます。 必要な間隔で提供されていない。ユーザーは資金を入金し、DON に挑戦できます。 チェックポイントが一連の有効なブロックを正しく表していることを証明するため(ある方法) たとえば、に似ています。 [141])。もちろん、ブロックの生成はトランザクションと同等ではありません ただし、SLA 契約は後者を強制する役割も果たします。たとえば、 FSS のレガシー互換バージョンでは、トランザクションがメモリプール (セクション 5.2 を参照) からフェッチされ、トランザクションは最終的にマイニングされてチェーン上に配置されます。ユーザー SLA 契約に以下のトランザクションを提供することで、DON の不正行為を証明できます。 マイニングされましたが、ターゲット コントラクトによる処理のために DON によって送信されませんでした 適切な時間内に。15 よりきめ細かい SLA の存在を証明し、罰則を課すことも可能です 実行可能ファイルを使用した計算エラーを含む失敗（たとえば、メカニズムを介して） セクション 6.3 で概説されているオフチェーン状態のトランザクションが正しいこと、または実行に失敗したことを証明するため DON で表示されるイニシエーターに基づく実行可能ファイル、DON 上のデータの中継に失敗する タイムリーなメインチェーンなど。

Kinh tế và kinh tế tiền điện tử

Để mạng Chainlink đạt được mức độ bảo mật mạnh mẽ trong mô hình tin cậy phi tập trung, điều cần thiết là các nút phải thể hiện hành vi đúng đắn một cách tập thể, nghĩa là chúng tuân thủ phần lớn thời gian đều chính xác với các giao thức DON. Trong phần này, chúng tôi thảo luận về các phương pháp để giúp thực thi hành vi đó bằng các biện pháp khuyến khích kinh tế, hay còn gọi là kinh tế tiền điện tử khuyến khích. Những ưu đãi này được chia thành hai loại: rõ ràng và tiềm ẩn, được thực hiện tương ứng thông qua staking và cơ hội thu phí trong tương lai (FFO). Đặt cọc: Đặt cược vào Chainlink, giống như trong các hệ thống blockchain khác, bao gồm những người tham gia mạng, tức là các nút oracle, gửi tiền bị khóa dưới dạng LINK tokens. Những cái này quỹ mà chúng tôi còn gọi là cổ phần hoặc cổ phần rõ ràng là một động lực rõ ràng. Họ có thể bị mất khi nút bị lỗi hoặc trục trặc. Trong ngữ cảnh blockchain, thủ tục này thường được gọi là chém. Tuy nhiên, việc đặt cược bởi các nút oracle trong Chainlink về cơ bản khác với staking bởi validator giây trong blockchain giây không được phép. Người xác nhận có thể hoạt động sai bằng cách đặt hàng các giao dịch không rõ ràng hoặc đối nghịch. Giao thức đồng thuận cơ bản trong một 15Vì người dùng có thể thay thế các giao dịch trong mempool nên cần phải cẩn thận để đảm bảo sự tương ứng chính xác giữa các giao dịch được khai thác và DON đã gửi.Tuy nhiên, blockchain không được phép sử dụng các quy tắc xác thực khối nhanh chóng và nguyên gốc bằng mật mã để ngăn validator tạo các khối không hợp lệ. Ngược lại, các biện pháp bảo vệ có lập trình không thể ngăn mạng oracle gian lận tạo ra báo cáo không hợp lệ. Lý do là sự khác biệt chính giữa hai loại hệ thống: xác thực giao dịch trong blockchains là thuộc tính của tính nhất quán nội bộ, trong khi tính chính xác của oracle báo cáo về blockchain là thuộc tính của dữ liệu bên ngoài, tức là dữ liệu ngoài chuỗi. Chúng tôi đã thiết kế cơ chế staking sơ bộ cho mạng Chainlink dựa trên trên giao thức tương tác giữa các nút oracle có thể sử dụng dữ liệu bên ngoài. Cái này cơ chế tạo ra các khuyến khích tài chính cho hành vi đúng đắn bằng cách sử dụng các phần thưởng và hình phạt (chém). Vì cơ chế này mang tính kinh tế nên nó được thiết kế để ngăn chặn nút tham nhũng bởi kẻ thù sử dụng nguồn tài chính để làm hỏng các nút bằng cách hối lộ. (Đối thủ như vậy rất chung chung và mở rộng, ví dụ: tới các nút hợp tác với rút ra giá trị từ hành vi sai trái tập thể của họ.) Cơ chế Chainlink staking mà chúng tôi đã thiết kế có một số cơ chế mạnh mẽ và mới lạ tính năng.16 Tính năng chính như vậy là tác động siêu tuyến tính staking (cụ thể là bậc hai). Đối thủ phải có tài nguyên vượt quá đáng kể số tiền gửi của các nút trong nhằm phá hoại cơ chế. Cơ chế staking của chúng tôi còn cung cấp thêm khả năng bảo vệ chống lại đối thủ mạnh hơn so với những gì đã được xem xét trước đây trong các hệ thống tương tự, cụ thể là một kẻ thù có thể đưa ra hối lộ điều chỉnh hành vi trong tương lai của các nút. Ngoài ra, chúng tôi còn thảo luận về cách các công cụ Chainlink như DECO có thể giúp củng cố staking của chúng tôi cơ chế bằng cách tạo điều kiện cho việc xét xử chính xác trong trường hợp nút hoạt động bị lỗi. Cơ hội thu phí trong tương lai (FFO): blockchains không được phép—của cả PoW và sự đa dạng của PoS—ngày nay chủ yếu dựa vào cái mà chúng tôi gọi là động cơ ngầm. Đây là khuyến khích kinh tế cho hành vi trung thực không xuất phát từ những phần thưởng rõ ràng, mà là từ chính sự tham gia của nền tảng. Ví dụ: cộng đồng thợ mỏ Bitcoin được khuyến khích chống lại việc thực hiện cuộc tấn công 51% do nguy cơ làm suy yếu niềm tin vào Bitcoin, làm giảm giá trị của nó và do đó làm xói mòn giá trị tập thể của họ đầu tư vốn vào cơ sở hạ tầng khai thác mỏ [150]. Mạng Chainlink được hưởng lợi từ động cơ ngầm tương tự mà chúng tôi đề cập đến như cơ hội phí trong tương lai (FFO). Các nút Oracle có lịch sử hiệu suất mạnh mẽ hoặc danh tiếng thu hút phí từ người dùng. Hành vi sai trái của nút oracle gây nguy hiểm cho tương lai thanh toán phí và do đó phạt nút bằng chi phí cơ hội về mặt tiềm năng doanh thu kiếm được thông qua việc tham gia vào mạng lưới. Bằng cách tương tự với cổ phần rõ ràng, FFO có thể được xem như một dạng cổ phần tiềm ẩn, một động cơ khuyến khích hành vi trung thực bắt nguồn từ lợi ích chung của việc duy trì niềm tin vào nền tảng mà trên đó Hoạt động kinh doanh của nhà khai thác nút phụ thuộc vào, tức là hiệu suất tích cực và danh tiếng của mạng. Khuyến khích này vốn có nhưng không được thể hiện rõ ràng trong mạng Chainlink giao thức. Trong Bitcoin, duy trì giá trị của hoạt động khai thác như đã đề cập ở trên 16Cơ chế staking mà chúng tôi mô tả ở đây hiện chỉ nhằm mục đích thực thi việc gửi báo cáo chính xác bởi oracle mạng. Chúng tôi hy vọng trong công việc tương lai sẽ mở rộng nó để đảm bảo thực hiện đúng nhiều các chức năng khác DON sẽ cung cấp.tương tự có thể được xem như một hình thức cổ phần tiềm ẩn. Chúng tôi nhấn mạnh rằng FFO đã tồn tại trong Chainlink và giúp bảo mật mạng hôm nay. Đóng góp chính của chúng tôi trong việc phát triển hơn nữa Chainlink sẽ là cách tiếp cận có nguyên tắc, dựa trên kinh nghiệm để đánh giá các biện pháp khuyến khích ngầm như FFO thông qua cái mà chúng tôi gọi là Khung khuyến khích tiềm ẩn (IIF). Để ước tính số lượng như cơ hội thu phí trong tương lai của các nút, IIF sẽ liên tục dựa trên toàn diện dữ liệu hiệu suất và thanh toán được mạng Chainlink tích lũy. Những ước tính như vậy sẽ cho phép tham số hóa dựa trên IIF của các hệ thống staking phản ánh khuyến khích nút với độ chính xác cao hơn các mô hình heuristic và/hoặc tĩnh hiện tại. Tóm lại, hai động lực kinh tế chính cho nút oracle chính xác hành vi trong mạng Chainlink đang phát triển sẽ là: • Đặt cọc (đặt cọc) ồ Khuyến khích rõ ràng • Cơ hội thu phí trong tương lai (FFO) ồ Khuyến khích ngầm Hai hình thức khuyến khích này bổ sung cho nhau. Các nút Oracle có thể đồng thời tham gia vào giao thức Chainlink staking, tận hưởng luồng doanh thu liên tục từ người dùng và cùng được hưởng lợi từ hành vi tốt liên tục của họ. Như vậy cả hai biện pháp khuyến khích góp phần bảo mật kinh tế tiền điện tử do mạng oracle cung cấp. Ngoài ra, hai động cơ khuyến khích này có thể củng cố và/hoặc được trao đổi với nhau. Ví dụ, toán tử oracle mới không có lịch sử hiệu suất và luồng doanh thu có thể đặt cược số lượng lớn LINK như một sự đảm bảo cho hành vi trung thực, từ đó thu hút người dùng và phí. Ngược lại, một toán tử oracle đã được thiết lập có thời gian dài, tương đối không có lỗi lịch sử hiệu suất có thể tính phí đáng kể từ cơ sở người dùng lớn và do đó dựa vào nặng nề hơn vào FFO của nó như một hình thức khuyến khích ngầm. Nói chung, cách tiếp cận mà chúng tôi xem xét ở đây nhằm vào số lượng oracle mạng nhất định nguồn lực để tạo ra các khuyến khích kinh tế lớn nhất có thể trong Chainlink cho hợp lý các đại lý—tức là các nút tối đa hóa tiện ích tài chính của họ—hành xử trung thực. Đặt cái khác theo cách này, mục tiêu là tối đa hóa nguồn tài chính cần thiết để đối thủ tấn công mạng thành công. Bằng cách xây dựng giao thức staking với tính toán tốt an ninh kinh tế được xác định và cũng sử dụng IIF, chúng tôi mong muốn đo lường sức mạnh của Ưu đãi của Chainlink chính xác nhất có thể. Những người tạo ra các hợp đồng dựa trên sẽ sau đó có thể xác định một cách chắc chắn liệu mạng oracle có đáp ứng được không mức độ bảo mật kinh tế tiền điện tử cần thiết của họ. Chu kỳ đạo đức của an ninh kinh tế: Các biện pháp khuyến khích mà chúng ta thảo luận trong phần này, staking và FFO, có tác động vượt ra ngoài việc tăng cường tính bảo mật của DONs. Họ hứa sẽ tạo ra cái mà chúng ta gọi là một chu kỳ an ninh kinh tế có đạo đức. Tác động siêu tuyến tính staking (và tính kinh tế theo quy mô khác) dẫn đến hiệu quả hoạt động thấp hơn chi phí khi mức độ bảo mật của DON tăng lên. Chi phí thấp hơn sẽ thu hút thêm người dùng vào DON,tăng cường thanh toán phí. Sự gia tăng trong thanh toán phí tiếp tục khuyến khích sự tăng trưởng của mạng lưới, giúp duy trì chu kỳ đạo đức. Chúng tôi tin rằng chu kỳ lành mạnh của an ninh kinh tế chỉ là một ví dụ về tính kinh tế theo quy mô và hiệu ứng mạng trong số những vấn đề khác mà chúng ta sẽ thảo luận sau trong phần này. Tổ chức phần: Đặt cọc đưa ra những thách thức đáng chú ý về mặt kỹ thuật và khái niệm cho mà chúng tôi đã thiết kế một cơ chế với các tính năng mới. Do đó, việc đặt cược sẽ được trọng tâm chính của chúng tôi trong phần này. Chúng tôi cung cấp tổng quan về cách tiếp cận staking mà chúng tôi giới thiệu trong bài viết này ở Phần 9.1, sau đó là thảo luận chi tiết trong Phần 9.2 đến 9.5. Chúng tôi trình bày IFF trong Phần 9.6. Chúng tôi trình bày quan điểm tóm tắt về Chainlink ưu đãi mạng trong Phần 9.7. Trong Phần 9.8, chúng tôi thảo luận về chu kỳ hợp lý của an ninh kinh tế mà phương pháp staking được đề xuất của chúng tôi có thể mang lại cho các mạng oracle. Cuối cùng, chúng tôi mô tả ngắn gọn các tiềm năng khác tác động thúc đẩy sự phát triển của mạng Chainlink trong Phần 9.9. 9.1 Tổng quan về đặt cược Thiết kế cơ chế staking mà chúng tôi giới thiệu ở đây, như đã lưu ý ở trên, bao gồm một giao thức tương tác giữa các nút oracle cho phép giải quyết sự không nhất quán trong báo cáo dữ liệu bên ngoài. Đặt cược nhằm mục đích đảm bảo hành vi trung thực từ các nút oracle hợp lý. Do đó, chúng ta có thể lập mô hình đối thủ tấn công giao thức staking dưới dạng kẻ hối lộ: Chiến lược của kẻ thù là mua chuộc các nút oracle bằng cách sử dụng các biện pháp khuyến khích tài chính. Kẻ thù có thể lấy được nguồn tài chính từ việc giả mạo thành công với báo cáo oracle, ví dụ: đề nghị chia sẻ lợi nhuận thu được với các nút bị hỏng. Chúng tôi hướng tới thiết kế cơ chế staking của mình đồng thời hai mục tiêu đầy tham vọng: 1. Chống lại kẻ thù hùng mạnh: Cơ chế staking được thiết kế để bảo vệ oracle mạng lưới chống lại một nhóm đối thủ rộng lớn có khả năng phức tạp, chiến lược hối lộ có điều kiện, bao gồm cả hối lộ tiềm năng, đưa hối lộ tới oracle có danh tính được xác định sau sự việc (ví dụ: đưa hối lộ cho oracle được chọn ngẫu nhiên để cảnh báo mức độ ưu tiên cao). Trong khi các thiết kế oracle khác đã xem xét một loạt các cuộc tấn công hẹp mà không có đầy đủ khả năng thực tế đối thủ, theo hiểu biết tốt nhất của chúng tôi, cơ chế đối nghịch mà chúng tôi giới thiệu đây là lần đầu tiên đề cập một cách rõ ràng một loạt các chiến lược hối lộ và chỉ ra kháng cự trong mô hình này. Mô hình của chúng tôi giả định rằng các nút bên cạnh kẻ tấn công là hợp lý về mặt kinh tế (trái ngược với trung thực) và chúng tôi giả định sự tồn tại của một nguồn sự thật cực kỳ tốn kém cho việc sử dụng thông thường nhưng có sẵn trong trường hợp không đồng ý (được thảo luận thêm bên dưới). 2. Đạt được tác động siêu tuyến tính staking: Mục tiêu của chúng tôi là đảm bảo rằng mạng oracle bao gồm các báo cáo tác nhân hợp lý trung thực ngay cả khi có sự hiện diện của kẻ tấn công với ngân sách siêu tuyến tínhtrong tổng số cổ phần được gửi bởi toàn bộ mạng lưới. Trong các hệ thống staking hiện có, nếu mỗi nút trong số n nút đặt cược $d, kẻ tấn công có thể đưa ra một khoản hối lộ đáng tin cậy yêu cầu các nút đó hành xử không trung thực để đổi lấy khoản thanh toán nhiều hơn một chút \(d to each node, using a total budget of about \)dn. Đây đã là một thanh cao như kẻ tấn công phải có một ngân sách thanh khoản theo thứ tự tổng số tiền gửi của tất cả các staker trong mạng. Mục tiêu của chúng tôi là mức độ an ninh kinh tế cao hơn nữa hơn trở ngại vốn đã đáng kể này. Chúng tôi mong muốn thiết kế hệ thống staking đầu tiên có thể đạt được sự bảo mật cho kẻ tấn công thông thường với ngân sách siêu tuyến tính trong n. Mặc dù những cân nhắc thực tế có thể đạt được tác động thấp hơn, như chúng tôi thảo luận dưới đây, thiết kế sơ bộ của chúng tôi đạt được yêu cầu ngân sách đối nghịch lớn hơn $dn2/2, tức là, chia tỷ lệ bậc hai theo n, thậm chí khiến việc hối lộ hầu như không thực tế khi các nút chỉ đặt cược số tiền vừa phải. Để đạt được hai mục tiêu này đòi hỏi sự kết hợp sáng tạo giữa thiết kế khuyến khích và mật mã. Ý tưởng chính: Cách tiếp cận staking của chúng tôi xoay quanh một ý tưởng mà chúng tôi gọi là ưu tiên của cơ quan giám sát. Báo cáo được tạo bởi mạng Chainlink oracle và được gửi tới hợp đồng phụ thuộc (ví dụ: về giá tài sản) được tổng hợp từ các báo cáo riêng lẻ do các nút tham gia đóng góp (ví dụ: bằng cách lấy giá trị trung bình). Điển hình là thỏa thuận cấp độ dịch vụ (SLA) chỉ định giới hạn độ lệch có thể chấp nhận được cho các báo cáo, tức là báo cáo của nút có thể đi được bao xa đi chệch khỏi báo cáo tổng hợp và mức độ tổng hợp được phép lệch khỏi giá trị thực thì được coi là đúng. Trong hệ thống staking của chúng tôi, đối với một vòng báo cáo nhất định, mỗi nút oracle có thể hoạt động như cơ quan giám sát đưa ra cảnh báo nếu họ tin rằng báo cáo tổng hợp là không chính xác. Trong mỗi vòng báo cáo, mỗi nút oracle được chỉ định một mức độ ưu tiên công khai xác định thứ tự cảnh báo của nó (nếu có) sẽ được xử lý. Cơ chế của chúng tôi nhằm mục đích khen thưởng tập trung, có nghĩa là cơ quan giám sát có mức độ ưu tiên cao nhất đưa ra cảnh báo sẽ nhận được toàn bộ phần thưởng thu được bằng cách tịch thu tiền gửi của các nút bị lỗi. Thiết kế hệ thống staking của chúng tôi bao gồm hai cấp: cấp đầu tiên, mặc định và cấp thứ hai, tầng cản trở. Tầng đầu tiên chính là mạng oracle, một tập hợp n nút. (Để đơn giản, chúng tôi giả sử n là số lẻ.) Nếu phần lớn các nút báo cáo giá trị không chính xác, cơ quan giám sát trong cấp đầu tiên được khuyến khích mạnh mẽ để đưa ra cảnh báo. Nếu cảnh báo được đưa ra, báo cáo quyết định của mạng sau đó được chuyển lên cấp thứ hai—một hệ thống có chi phí cao, độ tin cậy tối đa có thể được người dùng chỉ định trong thỏa thuận cấp độ dịch vụ mạng. Ví dụ, đây có thể là một hệ thống chỉ bao gồm các nút có điểm số về độ tin cậy lịch sử hoặc điểm có độ lớn hơn oracles so với bậc đầu tiên. Ngoài ra, như đã thảo luận trong Phần 9.4.3, DECO hoặc Town Crier có thể phục vụ là những công cụ mạnh mẽ giúp đảm bảo việc xét xử hiệu quả và có tính kết luận ở cấp độ thứ hai. Để đơn giản, chúng tôi giả định rằng hệ thống cấp hai này đưa ra một báo cáo chính xác giá trị. Mặc dù việc dựa vào cấp thứ hai để tạo tất cả các báo cáo có vẻ hấp dẫn, Lợi ích của thiết kế của chúng tôi là nó luôn đạt được các đặc tính bảo mật củahệ thống cấp hai trong khi chỉ phải trả chi phí vận hành, trong trường hợp điển hình, của hệ thống cấp một. Mức độ ưu tiên của cơ quan giám sát dẫn đến tác động staking siêu tuyến tính theo cách sau: nếu mạng oracle cấp một đưa ra kết quả không chính xác và một số nút cơ quan giám sát cảnh báo, cơ chế khuyến khích staking thưởng cho cơ quan giám sát có mức độ ưu tiên cao nhất hơn $dn/2 được rút từ tiền gửi của (phần lớn) các nút hoạt động sai. các do đó, tổng phần thưởng tập trung vào tay cơ quan giám sát duy nhất này, do đó xác định mức tối thiểu mà đối thủ phải hứa với một cơ quan giám sát tiềm năng để khuyến khích nó không cảnh báo. Vì cơ chế của chúng tôi đảm bảo rằng mọi oracle đều nhận được cơ hội đóng vai trò là cơ quan giám sát nếu các cơ quan giám sát có mức độ ưu tiên cao hơn đã nhận hối lộ của họ (và được chọn không cảnh báo), do đó đối thủ phải đưa hối lộ nhiều hơn $dn/2 tới mọi nút để ngăn chặn bất kỳ cảnh báo nào được đưa ra. Vì có n nút nên Ngân sách cần thiết của đối phương để hối lộ thành công lên tới hơn $dn2/2, tức là là bậc hai của số n nút trong mạng. 9,2 Nền Cách tiếp cận của chúng tôi đối với staking dựa trên nghiên cứu trong lĩnh vực lý thuyết và cơ chế trò chơi thiết kế (MD) (để tham khảo sách giáo khoa, xem [177]). Lý thuyết trò chơi là lý thuyết toán học nghiên cứu chính thức về tương tác chiến lược. Trong bối cảnh này, trò chơi là một mô hình của một sự tương tác, điển hình là trong thế giới thực, mã hóa các tập hợp hành động có sẵn để người tham gia trò chơi, được gọi là người chơi. Trò chơi cũng chỉ định số tiền nhận được bởi từng người chơi—phần thưởng phụ thuộc vào hành động được lựa chọn của người chơi và hành động của những người chơi khác. Có lẽ ví dụ nổi tiếng nhất về trò chơi được nghiên cứu trong trò chơi lý thuyết là Thế tiến thoái lưỡng nan của tù nhân [178]. Các nhà lý thuyết trò chơi thường hướng tới việc hiểu trạng thái cân bằng hoặc cân bằng (nếu có) thể hiện trong một trò chơi nhất định. Một trạng thái cân bằng là một tập hợp các chiến lược (mỗi người chơi một chiến lược) sao cho không người chơi nào có thể đạt được điểm cao hơn thanh toán bằng cách đơn phương đi chệch khỏi chiến lược của mình. Trong khi đó, thiết kế cơ chế là khoa học thiết kế các biện pháp khuyến khích sao cho trạng thái cân bằng của một tương tác (và trò chơi liên quan của nó) có một số đặc tính mong muốn. MD có thể được coi là nghịch đảo của lý thuyết trò chơi: Câu hỏi kinh điển trong trò chơi lý thuyết là “với các động cơ và mô hình được đưa ra, trạng thái cân bằng sẽ như thế nào?” Ở MD, Thay vào đó, câu hỏi là “những khuyến khích nào sẽ mang lại một trò chơi có trạng thái cân bằng mong muốn?” Mục tiêu điển hình của người thiết kế cơ chế là tạo ra một cơ chế 'tương thích khuyến khích', nghĩa là những người tham gia cơ chế (ví dụ: đấu giá hoặc thông tin khác) hệ thống gợi ý [228]) được khuyến khích báo cáo sự thật về một số vấn đề (ví dụ: làm thế nào họ đánh giá cao một mặt hàng cụ thể). Cuộc đấu giá Vickrey (giá thứ hai) có lẽ là cơ chế khuyến khích tương thích được biết đến nhiều nhất, trong đó người tham gia nộp hồ sơ dự thầu kín cho một món hàng và người trả giá cao nhất sẽ thắng món hàng đó nhưng phải trả mức giá cao thứ hai [214]. Kinh tế học mật mã là một dạng MD dành riêng cho từng miền, tận dụng kỹ thuật mã hóa kỹ thuật để tạo ra sự cân bằng mong muốn trong các hệ thống phi tập trung. Hối lộ và thông đồng tạo ra những thách thức đáng kể trong lĩnh vực MD. Hầu như tất cả các cơ chế đều bị phá vỡ khi có sự thông đồng, được định nghĩa là các hợp đồng phụgiữa các bên tham gia cơ chế [125, 130]. Hối lộ, trong đó một bên bên ngoài đưa các khuyến khích mới vào trò chơi, gây ra một vấn đề thậm chí còn khó khăn hơn hơn là thông đồng; thông đồng có thể được coi là một trường hợp đặc biệt của hối lộ trong trò chơi người tham gia. Các hệ thống chuỗi khối thường có thể được khái niệm hóa như một trò chơi với các khoản thanh toán bằng tiền (dựa trên tiền điện tử). Một ví dụ đơn giản là khai thác Bằng chứng công việc: thợ mỏ có không gian hành động trong đó họ có thể chọn tỷ lệ hash để khai thác khối. Lợi ích của việc khai thác là phần thưởng âm được đảm bảo (chi phí điện và thiết bị) cộng với chi phí ngẫu nhiên phần thưởng tích cực (trợ cấp khai thác) phụ thuộc vào số lượng người khai thác đang hoạt động khác [106, 172] và phí giao dịch. oracle được cộng đồng đóng góp như SchellingCoin [68] là một ví dụ khác: không gian hành động là tập hợp các báo cáo có thể có mà oracle có thể gửi, trong khi khoản thanh toán là phần thưởng được chỉ định bởi cơ chế oracle, ví dụ: khoản thanh toán có thể phụ thuộc vào về mức độ gần gũi giữa báo cáo của oracle với giá trị trung bình của các báo cáo khác [26, 68, 119, 185]. Trò chơi chuỗi khối mang lại cơ hội chín muồi cho các cuộc tấn công thông đồng và hối lộ; thực sự, smart contracts thậm chí có thể tạo điều kiện thuận lợi cho các cuộc tấn công như vậy [96, 165]. Có lẽ được biết đến nhiều nhất cuộc tấn công hối lộ vào oracle được cộng đồng sử dụng là cuộc tấn công p-plus-epsilon [67]. Cuộc tấn công này phát sinh trong bối cảnh cơ chế giống như SchellingCoin trong đó người chơi gửi báo cáo có giá trị boolean (nghĩa là sai hoặc đúng) và được thưởng p nếu họ đồng ý với sự đệ trình của đa số. Trong cuộc tấn công p-plus-epsilon, kẻ tấn công hứa hẹn một cách đáng tin cậy: ví dụ: trả tiền cho người dùng $p + ϵ để bỏ phiếu sai khi và chỉ khi ý kiến đa số là đúng. Kết quả là một trạng thái cân bằng, trong đó tất cả người chơi được khuyến khích báo cáo sai bất kể người chơi khác làm gì; do đó, kẻ hối lộ có thể xúi giục các nút thông qua việc hối lộ đã hứa để báo cáo sai sự thật mà không thực sự trả tiền hối lộ (!). Tuy nhiên, việc khám phá các chiến lược hối lộ khác trong bối cảnh oracle—và đặc biệt là oracle không sử dụng nguồn lực từ cộng đồng—đã bị giới hạn ở đối thủ khá yếu các mô hình. Ví dụ, trong bối cảnh PoW, các nhà nghiên cứu đã nghiên cứu các yếu tố phụ thuộc vào kết quả hối lộ, tức là hối lộ chỉ được trả nếu thông điệp mục tiêu được kiểm duyệt thành công và không xuất hiện trong một khối, bất kể hành động của từng người khai thác [96, 165]. Trong trường hợp Tuy nhiên, trong số oracle, ngoài cuộc tấn công p-plus-epsilon, chúng tôi chỉ biết về công việc trong một mô hình hối lộ có giới hạn nghiêm ngặt, trong đó người đưa hối lộ gửi hối lộ với điều kiện hành động của từng người chơi chứ không phải kết quả đạt được. Ở đây chúng tôi phác thảo các thiết kế của cơ chế khơi gợi thông tin vẫn mang tính khuyến khích tương thích ngay cả trong một mô hình đối nghịch mạnh, như được mô tả trong tiểu mục tiếp theo. 9,3 Giả định mô hình hóa Trong tiểu mục này, chúng tôi giải thích cách chúng tôi mô hình hóa hành vi và khả năng của người chơi trong hệ thống của chúng tôi, cụ thể là các nút oracle cấp một, các nút ở cấp hai (xác định) lớp và đối thủ.9.3.1 Mô hình khuyến khích cấp một: Tác nhân hợp lý Nhiều hệ thống blockchain dựa vào tính bảo mật dựa trên giả định về một số thông tin trung thực các nút tham gia. Các nút được xác định là trung thực nếu chúng tuân theo giao thức ngay cả khi khi việc làm đó không mang lại lợi ích tài chính cho họ. Hệ thống Bằng chứng công việc thường yêu cầu phần lớn quyền lực hash phải trung thực, hệ thống Bằng chứng cổ phần thường yêu cầu 2/3 tổng số cổ phần tham gia phải trung thực và thậm chí cả các hệ thống lớp 2 như Trọng tài [141] yêu cầu ít nhất một người tham gia trung thực. Khi lập mô hình cho cơ chế staking, chúng tôi đưa ra giả định yếu hơn nhiều. (Trở thành các giả định rõ ràng, yếu hơn có nghĩa là các thuộc tính bảo mật mạnh hơn và do đó được ưu tiên hơn.) Chúng tôi cho rằng đối thủ đã làm hỏng, tức là các quyền kiểm soát, một số (thiểu số) một phần của nút oracle cấp một. Chúng tôi lập mô hình các nút còn lại không phải là tác nhân trung thực, mà là tối đa hóa tiện ích kỳ vọng hợp lý. Các nút này hoạt động hoàn toàn theo các khuyến khích tài chính mang tính tư lợi, lựa chọn các hành động mang lại hiệu quả tài chính dự kiến. đạt được. Ví dụ: nếu một nút được đưa hối lộ lớn hơn phần thưởng thu được từ hành vi trung thực thì sẽ nhận hối lộ. Lưu ý về các nút đối nghịch: Theo mô hình tin cậy phổ biến cho hệ thống phi tập trung, chúng tôi giả định rằng tất cả các nút đều hợp lý, tức là tìm cách tối đa hóa doanh thu ròng, thay vì bị kiểm soát bởi một đối thủ độc hại. Tuy nhiên, những tuyên bố của chúng tôi— tác động đặc biệt là siêu tuyến tính hoặc bậc hai staking—giữ được cung cấp tiệm cận rằng tập hợp các nút bị kiểm soát đối nghịch tối đa là (1/2 −c)n, đối với một số giá trị dương hằng số c. 9.3.2 Mô hình xét xử cấp hai: Tính đúng đắn dựa trên giả định Hãy nhớ rằng một tính năng quan trọng của cơ chế staking của chúng tôi giúp đạt được bảo mật chống lại các nút hợp lý là hệ thống cấp hai của nó. Trong cơ chế staking được đề xuất của chúng tôi, bất kỳ oracle nào cũng có thể đưa ra cảnh báo cho biết rằng nó tin rằng đầu ra của cơ chế này là không chính xác. Một cảnh báo mang lại độ tin cậy cao hệ thống cấp hai kích hoạt và báo cáo kết quả chính xác. Vì vậy, một mô hình chính yêu cầu đối với cách tiếp cận của chúng tôi là sự đánh giá chính xác, tức là báo cáo chính xác của hệ thống bậc hai. Mô hình staking của chúng tôi giả định hệ thống cấp hai hoạt động như một nguồn sự thật không thể bị hỏng, có độ tin cậy tối đa. Một hệ thống như vậy có thể sẽ tốn kém và chậm, và do đó không phù hợp để sử dụng cho trường hợp điển hình. Tuy nhiên, trong trường hợp cân bằng, tức là khi hệ thống cấp một hoạt động chính xác thì hệ thống cấp hai sẽ không được gọi. Thay vào đó, sự tồn tại của nó giúp tăng cường tính bảo mật của toàn bộ hệ thống oracle bằng cách cung cấp một backstop có độ đảm bảo cao. Việc sử dụng lớp xét xử có độ tin cậy cao, chi phí cao tương tự như quy trình kháng cáo trung tâm của hầu hết các hệ thống tư pháp. Nó cũng đã phổ biến trong thiết kế của oracle hệ thống, ví dụ: [119, 185]. Chúng tôi thảo luận ngắn gọn các cách tiếp cận để hiện thực hóa cấp độ thứ hai trong cơ chế của chúng tôi ở Mục 9.4.3.Giao thức staking của chúng tôi sử dụng phán đoán chính xác giả định của hệ thống cấp hai như một mối đe dọa đáng tin cậy để buộc các nút oracle báo cáo chính xác. giao thức tịch thu một phần hoặc toàn bộ cổ phần của các nút oracle tạo báo cáo được xác định bởi hệ thống cấp hai là không chính xác. Do đó, các nút của Oracle bị ngăn chặn hoạt động sai bởi hình phạt tài chính phát sinh. Cách tiếp cận này có tính chất tương tự như cách được sử dụng trong lạc quan rollups, ví dụ: [141, 10]. 9.3.3 Mô hình đối nghịch Cơ chế staking của chúng tôi được thiết kế để thu thập thông tin trung thực đồng thời đạt được sự bảo mật trước một nhóm đối thủ được xác định rõ ràng và rộng rãi. Nó cải thiện các tác phẩm trước đó, hoặc bỏ qua mô hình đối thủ rõ ràng hoặc tập trung vào các phân nhóm đối thủ hẹp, ví dụ: đối thủ p-plus-epsilon đã thảo luận ở trên. Mục tiêu của chúng tôi là thiết kế staking cơ chế bảo mật đã được chứng minh chính thức chống lại đầy đủ các đối thủ có khả năng phải gặp trong thực tế. Chúng ta mô hình đối thủ của mình là có ngân sách cố định (có thể tham số hóa), ký hiệu là $B. Kẻ thù có thể liên lạc riêng lẻ và bí mật với mỗi oracle trong mạng và có thể bí mật đưa ra bất kỳ cá nhân nào oracle khoản hối lộ được đảm bảo phụ thuộc vào các kết quả có thể quan sát được một cách công khai của cơ chế. Kết quả xác định hối lộ có thể bao gồm, ví dụ: giá trị được báo cáo bởi oracle, bất kỳ tin nhắn công khai nào được gửi bởi bất kỳ oracle nào tới cơ chế (ví dụ: cảnh báo), các giá trị được báo cáo bởi người khác oracles và giá trị đầu ra theo cơ chế. Không có cơ chế nào có thể bảo mật trước kẻ tấn công với khả năng không giới hạn. Do đó, chúng tôi coi một số hành vi là không thực tế hoặc nằm ngoài phạm vi. Chúng tôi cho rằng kẻ tấn công của chúng tôi không thể phá vỡ các nguyên tắc mã hóa tiêu chuẩn và, như đã lưu ý ở trên, có một điểm cố định (nếu có khả năng lớn) ngân sách $B. Chúng tôi còn giả định thêm rằng đối thủ không kiểm soát liên lạc trong mạng oracle, cụ thể là nó không thể trì hoãn đáng kể lưu lượng giữa các nút cấp một và/hoặc cấp hai. (Việc đối phương có thể quan sát được hoạt động giao tiếp như vậy hay không còn tùy thuộc vào cơ chế cụ thể, như chúng tôi giải thích bên dưới.) Tuy nhiên, một cách không chính thức, như đã lưu ý ở trên, chúng tôi cho rằng đối thủ có thể: (1) Tham nhũng một phần của oracle nút ((1/2 −c)-phân số cho một số hằng số c), tức là kiểm soát hoàn toàn họ, và (2) Đưa hối lộ cho bất kỳ nút nào mong muốn, với khoản thanh toán được đảm bảo về các kết quả do đối thủ quy định, như được mô tả ở trên. Mặc dù chúng tôi không cung cấp một mô hình chính thức hoặc phân loại đầy đủ về đối thủ nhiều khả năng hối lộ trong báo cáo nghiên cứu chuyên sâu này, sau đây là ví dụ về các loại những kẻ hối lộ nằm trong mô hình của chúng tôi. Để đơn giản, chúng tôi giả sử rằng oracle phát ra Boolean báo cáo có giá trị đúng (w.l.o.g.) là đúng và kết quả cuối cùng được tính là tổng hợp các báo cáo này sẽ được sử dụng bởi smart contract. Của kẻ hối lộ mục đích là làm cho kết quả cuối cùng không chính xác, tức là sai. • Kẻ hối lộ vô điều kiện: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai. • Kẻ hối lộ xác suất: Kẻ hối lộ đưa hối lộ $b với xác suất q nào đó cho bất kỳ oracle nào báo cáo đó là sai.• Kẻ hối lộ có điều kiện đưa ra kết quả sai: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai với điều kiện là kết quả cuối cùng là sai. • Kẻ hối lộ không có cảnh báo: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai miễn là không có cảnh báo nào được đưa ra. • p-plus-epsilon Kẻ hối lộ: Kẻ hối lộ đề nghị hối lộ $b cho bất kỳ oracle nào báo cáo sai là miễn là phần lớn oracle không báo cáo sai. • Người hối lộ tiềm năng: Kẻ hối lộ đưa hối lộ trước $b cho bất kỳ oracle nào được chọn cho một vai trò ngẫu nhiên và báo cáo sai. Trong giao thức staking được đề xuất của chúng tôi, tất cả các nút hoạt động như cơ quan giám sát tiềm năng và chúng tôi có thể chỉ ra rằng sự ngẫu nhiên trong số các ưu tiên của cơ quan giám sát không có khả năng dẫn đến hối lộ. Nhiều bằng chứng công việc, proof-of-stake và các hệ thống được cấp phép dễ bị tấn công tuy nhiên, hối lộ cho thấy tầm quan trọng của việc xem xét vấn đề này trong bối cảnh đối thủ của chúng ta mô hình và đảm bảo rằng các giao thức staking của chúng tôi có khả năng phục hồi theo mô hình đó. Xem Phụ lục E để biết thêm chi tiết. 9.3.4 Bao nhiêu bảo mật kinh tế tiền điện tử là đủ? Một đối thủ hợp lý sẽ chỉ chi tiền để tấn công một hệ thống nếu nó có thể thu được lợi nhuận lớn hơn chi phí của nó. Do đó, đối với mô hình đối nghịch của chúng tôi và đề xuất staking cơ chế, $B có thể được xem như thước đo lợi nhuận tiềm năng mà đối thủ có thể có được để trích xuất từ việc dựa vào smart contract bằng cách làm hỏng mạng oracle và khiến nó để tạo ra một báo cáo hoặc tập hợp các báo cáo không chính xác. Khi quyết định xem mạng oracle cung cấp mức độ bảo mật kinh tế tiền điện tử phù hợp cho mục đích của mình, người dùng nên đánh giá mạng từ quan điểm này. Đối với những đối thủ đáng tin cậy trong bối cảnh thực tế, chúng tôi kỳ vọng rằng $B nhìn chung sẽ nhỏ hơn đáng kể so với tổng tài sản tính theo smart contracts. Trong hầu hết các trường hợp, nó Đối phương không thể chiếm được toàn bộ tài sản này. 9,4 Cơ chế đặt cược: Phác thảo Ở đây chúng tôi trình bày các ý chính và cấu trúc chung của cơ chế staking mà chúng tôi hiện đang xem xét. Để dễ trình bày, chúng tôi mô tả một cách đơn giản nhưng chậm (nhiều vòng) trong tiểu mục này. Tuy nhiên, chúng tôi lưu ý rằng kế hoạch này khá thiết thực. Với những đảm bảo kinh tế được cung cấp bởi cơ chế, tức là việc trừng phạt và khuyến khích các nút bị lỗi, nhiều người dùng có thể sẵn sàng chấp nhận báo cáo một cách lạc quan. Nói cách khác, những người dùng như vậy có thể chấp nhận báo cáo trước khi sự xét xử tiềm năng của cấp thứ hai. Người dùng không muốn chấp nhận báo cáo một cách lạc quan có thể chọn đợi cho đến khi giao thức việc thực thi chấm dứt, tức là cho đến khi xảy ra bất kỳ sự leo thang tiềm năng nào lên tầng thứ hai. Cái này, tuy nhiên, có thể làm chậm đáng kể thời gian xác nhận báo cáo. Do đó chúng tôi tóm tắtHình 15: Sơ đồ lược đồ staking có cảnh báo. Trong ví dụ này, 1⃝a đa số của các nút bị hỏng/bị mua chuộc và phát ra giá trị ˜r không chính xác, thay vì giá trị chính xác giá trị báo cáo r. Nút cơ quan giám sát 2⃝ gửi cảnh báo đến ủy ban cấp hai, 3⃝xác định và đưa ra giá trị báo cáo chính xác r, dẫn đến các nút bị hỏng mất tiền gửi của họ—mỗi $d vào nút cơ quan giám sát 4⃝. phác thảo một số tối ưu hóa mang lại kết quả nhanh hơn (một vòng) nếu nhiều hơn một chút thiết kế phức tạp trong Phần 9.5. Hãy nhớ lại rằng tầng đầu tiên trong cơ chế staking của chúng tôi bao gồm oracle cơ bản bản thân mạng. Cấu trúc chính của cơ chế của chúng tôi, như được mô tả ở trên, là trong mỗi vòng, mỗi nút có thể hoạt động như một “cơ quan giám sát” với mức độ ưu tiên nhất định và do đó nó có khả năng đưa ra cảnh báo nếu cơ chế đạt được đầu ra không chính xác ˜r, thay vì đầu ra đúng một r. Cảnh báo này gây ra độ phân giải cấp hai mà chúng tôi cho rằng đạt đến độ phân giải chính xác báo cáo. Các nút có báo cáo không chính xác sẽ bị trừng phạt, theo nghĩa là cổ phần của họ bị chém và trao cho cơ quan giám sát. Cấu trúc cơ bản này phổ biến trong các hệ thống oracle, như trong, ví dụ: [119, 185]. Sự đổi mới quan trọng trong thiết kế của chúng tôi, được đề cập ngắn gọn ở trên, là mọi nút đều được giao một mức độ ưu tiên riêng biệt trong việc sắp xếp các cơ quan giám sát tiềm năng. Tức là cơ quan giám sát được tạo cơ hội để cảnh báo theo thứ tự ưu tiên. Hãy nhớ lại rằng nếu một nút có ưu tiên cao nhất để đưa ra cảnh báo, nó sẽ nhận được khoản tiền gửi bị cắt giảm $d cho mỗi hành vi sai trái nút, với tổng số lớn hơn \(dn/2 = \)d × n/2, vì một báo cáo không chính xác ngụ ý một phần lớn các nút xấu. Do đó, đối thủ ít nhất phải trả phần thưởng này cho hối lộ một nút tùy ý. Do đó, để hối lộ phần lớn các nút, đối thủ phải trả một khoản tiền hối lộ lớn cho phần lớn các nút, cụ thể là hơn $dn2/2. Chúng tôi trình bày dưới dạng sơ đồ cách thức hoạt động của cảnh báo và cơ quan giám sát trong Hình 15.9.4.1 Chi tiết cơ chế khác Hệ thống chống hối lộ mà chúng tôi mô tả chi tiết hơn bây giờ là một bản phác thảo đơn giản về công trình hai tầng mà chúng tôi dự định xây dựng. Hầu hết trọng tâm của chúng tôi sẽ là mô tả mạng cấp một (từ đây gọi đơn giản là “mạng” nếu không phù hợp với ngữ cảnh) cùng với cơ chế khuyến khích và thủ tục chuyển lên cấp thứ hai. Hãy xem xét một mạng Chainlink bao gồm n nút oracle chịu trách nhiệm thường xuyên (ví dụ: mỗi phút một lần) báo cáo giá trị boolean (ví dụ: liệu thị trường có vốn hóa của BTC vượt quá ETH). Là một phần của cơ chế staking, các nút phải cung cấp hai khoản đặt cọc: một khoản đặt cọc $d có thể bị cắt giảm trong trường hợp không đồng ý với phần lớn và khoản đặt cọc của cơ quan giám sát $dw có thể bị cắt giảm trong trường hợp có lỗi leo thang. Chúng tôi giả định rằng các nút không thể sao chép nội dung gửi của các nút khác, ví dụ: thông qua sơ đồ tiết lộ cam kết như được thảo luận trong Phần 5.3. Trong mỗi vòng, các nút đầu tiên cam kết với báo cáo của họ và khi tất cả các nút đã cam kết (hoặc hết thời gian chờ), các nút tiết lộ báo cáo của họ. Đối với mỗi báo cáo được tạo, mọi nút cũng được cấp mức độ ưu tiên theo dõi từ 1 đến n được chọn ngẫu nhiên, trong đó 1 là mức độ ưu tiên hàng đầu. Ưu tiên này cho phép tập trung phần thưởng vào tay một cơ quan giám sát. Sau khi tất cả các báo cáo được công khai, một giai đoạn cảnh báo xảy ra sau đó. Qua một chuỗi n vòng (đồng bộ), nút có ưu tiên tôi có cơ hội cảnh báo ở vòng i. Chúng ta hãy xem xét các kết quả có thể xảy ra đối với cơ chế sau khi các nút được tiết lộ báo cáo của họ. Một lần nữa giả sử một báo cáo nhị phân, giả sử giá trị đúng là đúng và cái sai là sai. Cũng giả sử rằng cơ chế bậc một tạo ra đầu ra giá trị đa số theo các nút làm báo cáo cuối cùng r. Có ba kết quả có thể xảy ra trong cơ chế này: • Thỏa thuận hoàn chỉnh: Trong trường hợp tốt nhất, các nút đều hoàn toàn đồng ý: tất cả các nút có sẵn và đã cung cấp báo cáo kịp thời có cùng giá trị r (hoặc đúng hoặc sai). Trong trường hợp này, mạng chỉ cần chuyển tiếp r tới các hợp đồng dựa trên và thưởng cho mỗi nút một khoản thanh toán cố định cho mỗi vòng $p, số tiền này nhỏ hơn nhiều hơn $d. • Thỏa thuận một phần: Có thể một số nút đang ngoại tuyến hoặc có sự bất đồng về giá trị nào là đúng, nhưng hầu hết các nút đều báo cáo là đúng và chỉ có một báo cáo thiểu số sai. Trường hợp này cũng đơn giản thôi. Giá trị đa số (đúng) được tính toán, dẫn đến báo cáo đúng r. Tất cả các nút báo cáo r đều được thưởng $p trong khi oracle được báo cáo không chính xác có tiền gửi của họ giảm một cách khiêm tốn, ví dụ: 10 xu. • Cảnh báo: Trong trường hợp cơ quan giám sát tin rằng đầu ra của mạng không chính xác, nó công khai kích hoạt cảnh báo, chuyển cơ chế này sang mạng cấp hai. Khi đó có hai kết quả có thể xảy ra: – Cảnh báo đúng: Nếu mạng cấp hai xác nhận rằng đầu ra củaHình 16: Tăng chi phí của kẻ hối lộ thông qua các phần thưởng cảnh báo tập trung. Một sự hối lộ đối thủ phải hối lộ mỗi nút nhiều hơn phần thưởng mà nó có thể nhận được bằng cách cảnh báo (hiển thị dưới dạng thanh màu đỏ). Nếu phần thưởng cảnh báo được chia sẻ thì phần thưởng này có thể tương đối nhỏ. Phần thưởng cảnh báo tập trung làm tăng phần thưởng mà bất kỳ nút đơn lẻ nào cũng có thể có được (thanh cao màu đỏ). Do đó, tổng số tiền mà đối phương phải trả cho một khoản hối lộ khả thi (vùng màu xám) lớn hơn nhiều với phần thưởng cảnh báo tập trung hơn so với phần thưởng cảnh báo được chia sẻ. mạng cấp một không chính xác, nút cơ quan giám sát cảnh báo sẽ nhận được phần thưởng bao gồm tất cả các khoản tiền gửi bị cắt giảm, và do đó nhiều hơn $dn/2. – Cảnh báo lỗi: Nếu oracle cấp hai và cấp một đồng ý, thì mức tăng sẽ là được coi là bị lỗi và nút cảnh báo sẽ mất khoản tiền gửi $dw. Trong trường hợp chấp nhận báo cáo một cách lạc quan, cảnh báo của cơ quan giám sát không gây ra bất kỳ sự thay đổi nào trong việc thực hiện các hợp đồng căn cứ. Đối với các hợp đồng được thiết kế để chờ đợi khả năng được phân xử bởi ủy ban cấp hai, cơ quan giám sát sẽ trì hoãn cảnh báo nhưng không đình chỉ việc thực hiện hợp đồng. Hợp đồng cũng có thể chỉ định một chuyển đổi dự phòng DON trong thời gian xem xét. 9.4.2 Tác động đặt cược bậc hai Khả năng cho mọi nút hoạt động như một cơ quan giám sát, kết hợp với mức độ ưu tiên nghiêm ngặt của nút đảm bảo phần thưởng tập trung, cho phép cơ chế đạt được bậc hai staking tác động đối với từng loại kẻ tấn công hối lộ được mô tả trong Phần 9.3.3. Hãy nhớ lại rằng điều này có nghĩa cụ thể trong cài đặt của chúng tôi là, đối với một mạng có n nút, mỗi nút có tiền gửi $d, kẻ hối lộ thành công (thuộc bất kỳ loại nào ở trên) phải có ngân sách lớn hơn $dn2/2. Nói chính xác, kẻ hối lộ phải làm hỏng ít nhất (n+1)/2 nút, vì kẻ hối lộ phải làm hỏng phần lớn n nút (đối với n lẻ, theo giả định). Vì vậy, một cơ quan giám sát đứng ra kiếm được phần thưởng $d(n + 1)/2. Do đó, người hối lộ phải trả số tiền này cho mọi người.nút để đảm bảo rằng không có nút nào hoạt động như cơ quan giám sát. Chúng tôi đang làm việc để chứng tỏ một cách chính thức rằng nếu người hối lộ có ngân sách tối đa là $d(n2 + n)/2, khi đó trò chơi con sẽ có trạng thái cân bằng hoàn hảo của trò chơi giữa những kẻ hối lộ và oracle—nói cách khác, điểm cân bằng tại bất kỳ thời điểm nào trong quá trình chơi trò chơi—là người đưa hối lộ không được đưa hối lộ và mỗi oracle báo cáo giá trị thực của nó một cách trung thực. Ở trên chúng tôi đã giải thích tại sao một kẻ hối lộ thành công có thể yêu cầu một ngân sách lớn hơn đáng kể so với tổng số tiền gửi của nút. Để minh họa điều này kết quả trực quan, Hình 16 cho thấy tác động của phần thưởng cảnh báo tập trung bằng đồ họa. Như chúng ta thấy ở đó, nếu phần thưởng cho việc cảnh báo cơ quan giám sát—cụ thể là tiền gửi hối lộ các nút báo cáo sai)—được chia cho tất cả các cảnh báo tiềm năng, tổng số tiền bất kỳ nút cảnh báo riêng lẻ nào có thể mong đợi sẽ tương đối nhỏ, theo thứ tự $d. Một kẻ hối lộ biết rằng khoản tiền lớn hơn $d là không thể xảy ra nên có thể sử dụng một khoản hối lộ có điều kiện có kết quả sai để hối lộ từng nút trong số n nút nhiều hơn một chút $d + ϵ. Ngược lại, Hình 16 cho thấy rằng một hệ thống phân phối phần thưởng một cách rộng rãi giữa các nút báo hiệu cảnh báo yếu hơn nhiều so với nút tập trung phần thưởng vào bàn tay của một cơ quan giám sát duy nhất. Các tham số ví dụ: Hãy xem xét một mạng (cấp đầu tiên) có n = 100 nút, mỗi nút gửi tiền \(d = \)20K. Mạng này sẽ có tổng số tiền gửi là 2 triệu USD nhưng sẽ được bảo vệ khỏi kẻ hối lộ với ngân sách \(100M = \)dn2/2. Tăng số lượng Tất nhiên, oracles sẽ hiệu quả hơn việc tăng $d và có thể có tác động mạnh mẽ: một mạng có n = 300 nút và tiền gửi \(d = \)20K sẽ được bảo vệ chống lại một kẻ hối lộ với ngân sách lên tới 900 triệu USD. Lưu ý rằng trong nhiều trường hợp, hệ thống staking có thể bảo vệ smart contract đại diện có giá trị cao hơn mức độ bảo vệ chống hối lộ được đưa ra. Điều này là do đối thủ tấn công các hợp đồng này không thể trích xuất toàn bộ giá trị trong nhiều trường hợp. Ví dụ, một Hợp đồng do Chainlink cung cấp đảm bảo giá trị 1 tỷ USD chỉ có thể yêu cầu bảo đảm chống lại một kẻ hối lộ với nguồn lực 100 triệu đô la vì kẻ thù như vậy có thể kiếm được lợi nhuận chỉ 10% giá trị hợp đồng. Lưu ý: Ý tưởng rằng giá trị của một mạng có thể tăng theo phương pháp bậc hai được thể hiện trong Định luật Metcalfe nổi tiếng [167, 235], trong đó nêu rõ rằng giá trị của một mạng tăng bậc hai về số lượng thực thể được kết nối. Tuy nhiên, định luật Metcalfe phát sinh từ sự tăng trưởng về số lượng kết nối mạng theo cặp tiềm năng, một hiện tượng khác với tác động bậc hai cơ bản staking trong khuyến khích của chúng tôi cơ chế. 9.4.3 Hiện thực hóa tầng thứ hai Hai tính năng vận hành tạo điều kiện thuận lợi cho việc hiện thực hóa tầng thứ hai có độ tin cậy cao: (1) Việc phân xử cấp hai phải là một sự kiện hiếm gặp trong các mạng oracle và do đó có thể tốn kém hơn đáng kể so với hoạt động bình thường của cấp một và (2) Giả sửnhững báo cáo được chấp nhận một cách lạc quan—hoặc những hợp đồng mà việc thực hiện có thể chờ phân xử— tầng thứ hai không cần thực thi trong thời gian thực. Những đặc điểm này dẫn đến một loạt các các tùy chọn cấu hình cho tầng thứ hai để đáp ứng các yêu cầu của DON cụ thể. Theo cách tiếp cận ví dụ, một ủy ban cấp hai có thể bao gồm các nút được chọn bởi một DON (tức là cấp đầu tiên) từ các nút hoạt động lâu nhất và đáng tin cậy nhất trong Chainlink mạng. Ngoài kinh nghiệm hoạt động có liên quan đáng kể, các nhà khai thác trong số các nút như vậy có động cơ ngầm đáng kể trong FFO thúc đẩy mong muốn để đảm bảo rằng mạng Chainlink vẫn có độ tin cậy cao. Họ cũng đã công khai lịch sử hiệu suất có sẵn cung cấp sự minh bạch về độ tin cậy của chúng. Điều đáng chú ý là các nút cấp hai không cần phải là người tham gia vào mạng cấp một và có thể phân xử các lỗi trên nhiều mạng cấp một. Các nút trong DON nhất định có thể chỉ định trước và cam kết công khai với một tập hợp n′ như vậy các nút cấu thành ủy ban cấp hai cho DON đó. Ngoài ra, DON các nút xuất bản tham số k′ ≤n′ xác định số phiếu bầu cấp hai cần thiết để trừng phạt nút cấp một. Khi cảnh báo được tạo cho một báo cáo nhất định, các thành viên của cấp thứ hai bỏ phiếu về tính chính xác của các giá trị do mỗi người cung cấp của các nút lớp đầu tiên. Bất kỳ nút cấp 1 nào nhận được k′ phiếu bầu tiêu cực sẽ bị mất quyền tiền gửi đến nút cơ quan giám sát. Bởi vì hiếm có cơ hội xét xử và cơ hội thi hành án kéo dài đã lưu ý ở trên, trái ngược với tầng thứ nhất, các nút ở tầng thứ hai có thể: 1. Được trả thù lao cao khi tiến hành xét xử. 2. Sử dụng các nguồn dữ liệu bổ sung, thậm chí vượt ra ngoài tập hợp đa dạng được sử dụng đầu tiên. 3. Dựa vào sự kiểm tra và can thiệp thủ công và/hoặc chuyên gia, ví dụ: để xác định và điều chỉnh các lỗi trong dữ liệu nguồn và phân biệt giữa một nút chuyển tiếp trung thực dữ liệu bị lỗi và một nút hoạt động sai. Chúng tôi nhấn mạnh rằng cách tiếp cận mà chúng tôi vừa mô tả để lựa chọn các nút cấp hai và việc xét xử quản lý chính sách chỉ đại diện cho một điểm trong một phạm vi rộng lớn. không gian thiết kế của các khả năng thực hiện của tầng thứ hai. Cơ chế khuyến khích của chúng tôi cung cấp hoàn toàn linh hoạt về cách thực hiện tầng thứ hai. Do đó, DON cá nhân có thể cấu thành và đặt ra các quy tắc cho cấp thứ hai đáp ứng các yêu cầu cụ thể và kỳ vọng của các nút tham gia và người dùng. DECO và Town Crier làm công cụ xét xử: Nó rất cần thiết cho tầng thứ hai trong cơ chế của chúng tôi để có thể phân biệt giữa các nút cấp một đối thủ cố ý tạo ra các báo cáo không chính xác và các nút cấp một trung thực vô tình chuyển tiếp dữ liệu không chính xác tại nguồn. Chỉ khi đó tầng thứ hai mới có thể thực hiện chém để ngăn chặn gian lận, mục tiêu của cơ chế của chúng tôi. DECO và Town Crier là những công cụ mạnh mẽ có thể cho phép các nút cấp hai tạo ra sự khác biệt quan trọng này đáng tin cậy.Trong một số trường hợp, các nút cấp hai có thể truy vấn trực tiếp nguồn dữ liệu được sử dụng bởi nút cấp một hoặc sử dụng ADO Mục 7.1 để kiểm tra xem báo cáo không chính xác có do nguồn dữ liệu bị lỗi. Tuy nhiên, trong các trường hợp khác, các nút cấp hai có thể thiếu truy cập trực tiếp vào nguồn dữ liệu của nút cấp một. Trong những trường hợp như vậy, việc xét xử đúng sẽ dường như không khả thi hoặc đòi hỏi phải dựa vào đánh giá chủ quan. Trước oracle các hệ thống tranh chấp đã dựa vào các vòng bỏ phiếu leo thang, không hiệu quả để giải quyết các vấn đề đó những thách thức. Tuy nhiên, bằng cách sử dụng DECO hoặc Town Crier, nút cấp một có thể chứng minh hành vi đúng tới các nút lớp thứ hai. (Xem Phần 3.6.2 để biết chi tiết về hai hệ thống.) Cụ thể, nếu nút cấp thứ hai xác định nút cấp một có giá trị báo cáo bị lỗi ˜r, nút cấp một có thể sử dụng DECO hoặc Town Crier để tạo ra bằng chứng chống giả mạo cho các nút cấp hai đang chuyển tiếp chính xác từ nguồn (kích hoạt TLS) được công nhận là có thẩm quyền bởi DON. Điều quan trọng là nút cấp một có thể thực hiện việc này không có các nút cấp hai yêu cầu quyền truy cập trực tiếp vào nguồn dữ liệu.17 Do đó, việc đánh giá chính xác là khả thi ở Chainlink đối với bất kỳ nguồn dữ liệu mong muốn nào. 9.4.4 Báo cáo sai bảo hiểm Khả năng chống hối lộ mạnh mẽ mà cơ chế staking của chúng tôi đạt được về cơ bản phụ thuộc vào về số tiền bị cắt giảm được trao cho người cảnh báo. Nếu không có phần thưởng bằng tiền, người cảnh báo sẽ không có động cơ trực tiếp để từ chối hối lộ. Tuy nhiên, kết quả là số tiền bị cắt giảm không phải là có sẵn để bồi thường cho người dùng bị tổn hại do báo cáo không chính xác, ví dụ: người dùng bị mất tiền khi dữ liệu giá không chính xác được chuyển tiếp tới smart contract. Theo giả định, các báo cáo không chính xác sẽ không gây ra vấn đề gì nếu báo cáo được một cơ quan chấp nhận. chỉ ký hợp đồng sau khi có sự phân xử tiềm năng, tức là hành động của cấp thứ hai. Như đã giải thích Tuy nhiên, ở trên, để đạt được hiệu suất tốt nhất có thể, thay vào đó, hợp đồng có thể dựa vào lạc quan về cơ chế thực thi việc báo cáo đúng, nghĩa là họ chấp nhận báo cáo trước khi xét xử cấp hai tiềm năng. Quả thực, hành vi lạc quan như vậy là an toàn trong mô hình của chúng tôi giả sử các đối thủ hợp lý có ngân sách không vượt quá staking tác động của cơ chế. Người dùng lo ngại về khả năng xảy ra lỗi cơ chế do, ví dụ: đối thủ có nguồn tài chính dồi dào, có thể muốn sử dụng một lớp bảo đảm kinh tế bổ sung dưới hình thức bảo hiểm báo cáo sai. Chúng tôi biết về nhiều công ty bảo hiểm đã có ý định cung cấp các chính sách hỗ trợ hợp đồng thông minh thuộc loại này cho các giao thức được bảo mật Chainlink trong tương lai gần, bao gồm thông qua các cơ chế cải tiến như DAOs, ví dụ: [7]. Sự tồn tại của lịch sử hiệu suất cho Chainlink các nút và dữ liệu khác về các nút, chẳng hạn như số tiền đặt cọc của chúng, cung cấp cơ sở đặc biệt mạnh mẽ để đánh giá rủi ro theo mô hình thống kê, giúp cho việc định giá chính sách có thể thực hiện được. theo những cách không tốn kém cho người mua bảo hiểm nhưng vẫn bền vững cho các công ty bảo hiểm. 17Với Town Crier, các nút cấp một cũng có thể tạo chứng thực cục bộ về tính chính xác của các báo cáo mà họ xuất ra và cung cấp những chứng thực này cho các nút cấp hai trên một cơ sở theo nhu cầu.Các hình thức báo cáo sai cơ bản về bảo hiểm có thể được thực hiện một cách đáng tin cậy và cách hiệu quả bằng cách sử dụng smart contracts. Một ví dụ đơn giản, một bảo hiểm tham số SCins hợp đồng có thể tự động bồi thường cho các chủ hợp đồng nếu cơ chế khuyến khích của chúng tôi cấp thứ hai xác định lỗi trong báo cáo được tạo ở cấp đầu tiên. Người dùng U mong muốn mua hợp đồng bảo hiểm, ví dụ: người tạo mục tiêu hợp đồng SC, có thể gửi yêu cầu tới một công ty bảo hiểm phi tập trung về số tiền hợp đồng $M trên hợp đồng. Khi phê duyệt U, công ty bảo hiểm có thể đặt ra thời hạn liên tục (ví dụ: hàng tháng) phí bảo hiểm $P trong SCins. Trong khi U trả phí bảo hiểm, hợp đồng của cô ấy vẫn có hiệu lực. Nếu xảy ra lỗi báo cáo trong SC thì kết quả sẽ là phát ra một cặp (r1, r2) về các báo cáo xung đột cho SC, trong đó r1 được ký bởi cấp đầu tiên trong cơ chế của chúng tôi và r2, báo cáo đã sửa tương ứng, được cấp thứ hai ký. Nếu U cung cấp một cặp hợp lệ (r1, r2) cho SCins, hợp đồng sẽ tự động trả cho cô ấy M $, với điều kiện là các khoản thanh toán phí bảo hiểm của cô ấy được cập nhật. 9,5 Biến thể một vòng Giao thức được mô tả trong tiểu mục trước yêu cầu ủy ban cấp hai đợi n vòng để xác định xem cơ quan giám sát có đưa ra cảnh báo hay không. Cái này yêu cầu vẫn đúng ngay cả trong trường hợp lạc quan, tức là khi tầng đầu tiên hoạt động một cách chính xác. Đối với người dùng không muốn chấp nhận các báo cáo một cách lạc quan, tức là trước khi có khả năng xảy ra xét xử, sự chậm trễ liên quan đến cách tiếp cận đó sẽ không thể thực hiện được. Vì lý do này, chúng tôi cũng đang khám phá các giao thức thay thế chỉ yêu cầu một tròn. Theo cách tiếp cận này, tất cả các nút oracle gửi các bit bí mật cho biết có hay không họ muốn đưa ra một cảnh báo. Ủy ban cấp hai sau đó sẽ kiểm tra các giá trị này trong thứ tự ưu tiên. Để cung cấp một bản phác thảo thô, sơ đồ như vậy có thể bao gồm những điều sau đây: các bước: 1. Gửi bit cơ quan giám sát: Mỗi nút Oi chia sẻ bí mật một giá trị cơ quan giám sát một bit wi ∈{không có cảnh báo, cảnh báo} giữa các nút ở cấp thứ hai cho mỗi báo cáo mà nó tạo ra. 2. Mẹo ẩn danh: Bất kỳ nút oracle nào cũng có thể gửi mẹo ẩn danh α tới ủy ban cấp hai trong cùng vòng mà các bit cơ quan giám sát được gửi. Mẹo này à là thông báo cho biết cảnh báo đã được đưa ra cho báo cáo hiện tại. 3. Kiểm tra bit cơ quan giám sát: Ủy ban cấp hai tiết lộ cơ quan giám sát của nút oracle các bit theo thứ tự ưu tiên. Lưu ý rằng các nút không được gửi các bit cơ quan giám sát cảnh báo khi chúng không cảnh báo: nếu không, phân tích lưu lượng sẽ tiết lộ tất cả các bit của nút. Giao thức không tiết lộ cảnh báo không các bit cơ quan giám sát của các nút có mức độ ưu tiên cao hơn cơ quan giám sát cảnh báo có mức ưu tiên cao nhất. Quan sát rằng những gì được tiết lộ giống hệt với giao thức vòng n của chúng tôi. Phần thưởng cũng được phân phối giống hệt với chương trình đó, tức là cơ quan giám sát được xác định đầu tiên nhận được khoản tiền gửi bị cắt giảm của các nút đã gửi báo cáo không chính xác.Việc sử dụng các mẹo ẩn danh cho phép ủy ban cấp hai duy trì trạng thái không tương tác trong trường hợp không có cảnh báo nào được đưa ra, giảm độ phức tạp trong giao tiếp trong trường hợp thông thường. Lưu ý rằng bất kỳ cơ quan giám sát nào đưa ra cảnh báo đều có động cơ kinh tế để gửi mẹo ẩn danh: Nếu không gửi mẹo nào, sẽ không có phần thưởng nào được trả cho bất kỳ ai. nút. Để đảm bảo rằng người gửi Oi của một mẹo ẩn danh α không thể được xác định bởi đối thủ dựa trên dữ liệu mạng, mẹo ẩn danh có thể được gửi qua địa chỉ ẩn danh kênh, ví dụ: thông qua Tor hoặc thực tế hơn là được ủy quyền thông qua nhà cung cấp dịch vụ đám mây. Đến xác thực mẹo có nguồn gốc từ O, Oi có thể ký α bằng chữ ký vòng [39, 192]. Ngoài ra, để ngăn chặn các cuộc tấn công từ chối dịch vụ không thể phân bổ nhằm vào ủy ban cấp hai bằng nút oracle độc hại, α có thể là thông tin xác thực ẩn danh với ẩn danh có thể hủy bỏ [73]. Giao thức này, mặc dù có thể đạt được trên thực tế, nhưng có kỹ thuật hơi nặng nề yêu cầu (mà chúng tôi đang tìm cách giảm bớt). Ví dụ, các nút cấp một, phải giao tiếp trực tiếp với các nút cấp hai, yêu cầu duy trì một thư mục. Nhu cầu về các kênh ẩn danh và chữ ký vòng làm tăng thêm kỹ thuật sự phức tạp của sơ đồ. Cuối cùng, có một yêu cầu tin cậy đặc biệt được thảo luận ngắn gọn trong ghi chú dưới đây. Do đó, chúng tôi cũng đang khám phá các kế hoạch đơn giản hơn mà vẫn đạt được tác động siêu tuyến tính staking, nhưng có lẽ ít hơn bậc hai, chẳng hạn, trong đó kẻ hối lộ tiệm cận cần tài nguyên ít nhất $n log n. Một số phương án theo việc xem xét liên quan đến việc lựa chọn ngẫu nhiên một tập hợp con nghiêm ngặt các nút để hoạt động như cơ quan giám sát, trong trường hợp đó việc hối lộ tiềm năng sẽ trở thành một cuộc tấn công đặc biệt mạnh mẽ. Nhận xét: Tính bảo mật của cơ chế staking một vòng này yêu cầu không thể truy cập được các kênh giữa oracle và các nút cấp hai—một yêu cầu tiêu chuẩn trong các hệ thống chống cưỡng chế, ví dụ: biểu quyết [82, 138] và một yêu cầu hợp lý trong thực tế. Tuy nhiên, ngoài ra, nút Oi tìm cách hợp tác với kẻ hối lộ có thể xây dựng các chia sẻ bí mật của nó theo cách để cho kẻ hối lộ thấy rằng nó đã mã hóa một thông tin cụ thể giá trị. Ví dụ: nếu Oi không biết kẻ hối lộ kiểm soát nút nào thì Oi có thể gửi cổ phiếu có giá trị 0 cho tất cả các thành viên ủy ban. Sau đó, kẻ hối lộ có thể xác minh Oi tuân thủ theo xác suất. Để tránh vấn đề này trong bất kỳ giao thức một vòng nào, chúng tôi yêu cầu Oi biết danh tính của ít nhất một nút cấp hai trung thực. Với giao thức tương tác trong đó mỗi nút cấp hai thêm một sự ngẫu nhiên yếu tố chia sẻ, điều tốt nhất mà kẻ hối lộ có thể làm là ép buộc Oi lựa chọn ngẫu nhiên chút canh gác. 9,6 Khung khuyến khích tiềm ẩn (IIF) FFO là một hình thức khuyến khích ngầm cho hành vi đúng trong mạng Chainlink. Nó các chức năng như cổ phần rõ ràng, tức là tiền gửi, trong đó nó giúp thực thi an ninh kinh tế cho mạng lưới. Nói cách khác, FFO nên được đưa vào như một phần của khoản tiền gửi (có hiệu lực) $d của một nút trong mạng.Câu hỏi đặt ra là: Làm cách nào để đo lường FFO và các hình thức khuyến khích tiềm ẩn khác? trong mạng Chainlink? Khung khuyến khích tiềm ẩn (IIF) là một tập hợp các nguyên tắc và kỹ thuật mà chúng tôi dự định phát triển cho mục đích này. Hệ thống chuỗi khối cung cấp nhiều hình thức minh bạch chưa từng có và các bản ghi có độ tin cậy cao của nút hiệu suất mà họ tạo ra là bàn đạp cho tầm nhìn của chúng tôi về cách thức hoạt động của IIF. Ở đây chúng tôi phác thảo rất ngắn gọn các ý tưởng về các yếu tố chính của IIF. Bản thân IIF sẽ bao gồm một tập hợp các yếu tố mà chúng tôi xác định là quan trọng trong việc đánh giá các biện pháp khuyến khích tiềm ẩn, cùng với các cơ chế xuất bản dữ liệu liên quan ở dạng có độ bảo đảm cao để các thuật toán phân tích sử dụng. Những người dùng Chainlink khác nhau có thể muốn sử dụng IIF theo nhiều cách khác nhau, ví dụ: đưa ra trọng số khác nhau cho các yếu tố khác nhau. Chúng tôi hy vọng các dịch vụ phân tích sẽ xuất hiện trong cộng đồng giúp người dùng áp dụng IIF theo sở thích đánh giá rủi ro cá nhân của họ và mục tiêu của chúng tôi là tạo điều kiện thuận lợi các dịch vụ đó bằng cách đảm bảo quyền truy cập của họ vào dữ liệu hỗ trợ kịp thời và có độ bảo đảm cao, như chúng ta thảo luận dưới đây (Phần 9.6.4). 9.6.1 Cơ hội phí trong tương lai Các nút tham gia vào hệ sinh thái Chainlink để kiếm được một phần phí mà mạng chi trả cho bất kỳ dịch vụ nào trong số các dịch vụ khác nhau mà chúng tôi đã mô tả trong bài viết này, từ nguồn cấp dữ liệu thông thường đến các dịch vụ nâng cao như nhận dạng phi tập trung, sắp xếp công bằng, và bảo mật DeFi. Các khoản phí trong mạng Chainlink hỗ trợ chi phí của người vận hành nút, ví dụ: chạy máy chủ, lấy giấy phép dữ liệu cần thiết và duy trì một đội ngũ nhân viên toàn cầu để đảm bảo thời gian hoạt động cao. FFO biểu thị phí dịch vụ, chi phí ròng, rằng một nút sẽ được lợi trong tương lai—hoặc bị mất nếu nó thể hiện hành vi bị lỗi. FFO là một hình thức stake giúp bảo mật mạng. Một tính năng hữu ích của FFO là dữ liệu trên chuỗi (được bổ sung bởi các dữ liệu ngoài chuỗi data) thiết lập bản ghi có độ tin cậy cao về lịch sử của nút, cho phép tính toán FFO một cách minh bạch, mang tính thực nghiệm. Một phép đo FFO đơn giản, bậc nhất có thể được lấy từ doanh thu ròng trung bình của một nút trong một khoảng thời gian (tức là tổng doanh thu trừ đi chi phí hoạt động). FFO có thể sau đó được tính như sau, ví dụ: giá trị hiện tại ròng [114] của doanh thu ròng tích lũy trong tương lai, nói cách khác, giá trị chiết khấu theo thời gian của tất cả thu nhập trong tương lai. Tuy nhiên, doanh thu từ nút có thể không ổn định, như minh họa trong Hình 17. Quan trọng hơn, doanh thu từ nút có thể không tuân theo sự phân phối cố định theo thời gian. Do đó, các yếu tố khác mà chúng tôi dự định khám phá khi ước tính FFO bao gồm: • Lịch sử hiệu suất: Lịch sử hiệu suất của nhà điều hành—bao gồm tính chính xác và kịp thời của các báo cáo cũng như thời gian hoạt động của nó—cung cấp một mục tiêu tiêu chuẩn để người dùng đánh giá độ tin cậy của nó. Do đó, lịch sử hiệu suất sẽ cung cấp yếu tố quan trọng trong việc người dùng lựa chọn các nút oracle (hoặc, với sự xuất hiện trong số DONs, lựa chọn DONs của họ). Một lịch sử hiệu suất mạnh mẽ có thể tương quan với doanh thu liên tục cao.18 18Một câu hỏi nghiên cứu quan trọng mà chúng tôi dự định giải quyết là phát hiện khối lượng dịch vụ giả mạo.Hình 17: Doanh thu kiếm được từ các nút Chainlink trên một nguồn cấp dữ liệu duy nhất (ETH-USD) trong một tuần điển hình vào tháng 3 năm 2021. • Truy cập dữ liệu: Mặc dù oracles có thể lấy nhiều dạng dữ liệu từ các API mở, một số dạng dữ liệu nhất định hoặc một số nguồn chất lượng cao nhất định có thể chỉ có sẵn trên một cơ sở đăng ký hoặc thông qua các thỏa thuận hợp đồng. Quyền truy cập đặc quyền vào một số nguồn dữ liệu có thể đóng vai trò tạo ra nguồn doanh thu ổn định. • Sự tham gia của DON: Với sự xuất hiện của DONs, cộng đồng các nút sẽ xuất hiện cùng nhau cung cấp các dịch vụ cụ thể. Chúng tôi hy vọng rằng nhiều DON sẽ bao gồm các nhà khai thác trên cơ sở chọn lọc, thiết lập sự tham gia vào các DON có uy tín với tư cách là một vị trí thị trường đặc quyền giúp đảm bảo nguồn doanh thu ổn định. • Hoạt động đa nền tảng: Một số nhà khai thác nút có thể có sự hiện diện và hồ sơ theo dõi hiệu suất được thiết lập tốt trong các bối cảnh khác, ví dụ: như PoS validators hoặc nhà cung cấp dữ liệu trong ngữ cảnh không phải blockchain. Hiệu suất của chúng trong các hệ thống khác này (khi dữ liệu trên đó có sẵn ở dạng đáng tin cậy) có thể đưa ra đánh giá lịch sử hoạt động của họ. Tương tự, hành vi bị lỗi trong mạng Chainlink có thể gây nguy hiểm cho doanh thu trong các hệ thống khác này bằng cách khiến người dùng rời xa, tức là FFO có thể mở rộng trên các nền tảng. 9.6.2 FFO đầu cơ Các nhà khai thác nút tham gia vào mạng Chainlink không chỉ để tạo doanh thu từ mà là tạo dựng và định vị bản thân để tận dụng các cơ hội mới để thực hiện công việc. Nói cách khác, chi tiêu của các nút oracle trong mạng cũng tuyên bố tích cực về tương lai của DeFi và ứng dụng hợp đồng thông minh khác các miền cũng như các ứng dụng không thuộc blockchain mới nổi của mạng oracle. Các nhà khai thác nút ngày nay kiếm được khoản phí có sẵn trên các mạng Chainlink hiện có và đồng thời Những điều này gần giống với các đánh giá giả mạo trên các trang internet, ngoại trừ vấn đề dễ xảy ra hơn ở phần oracle cài đặt vì chúng tôi có hồ sơ chính xác về việc hàng hóa, tức là các báo cáo, đã được đặt hàng và chưa được giao—trái ngược với, ví dụ: hàng hóa vật chất được đặt hàng trong các cửa hàng trực tuyến. Nói cách khác, trong oracle cài đặt, hiệu suất có thể được xác thực, ngay cả khi tính xác thực của khách hàng không thể.xây dựng danh tiếng, lịch sử hoạt động và chuyên môn điều hành sẽ định vị họ một cách thuận lợi để kiếm được phí sẵn có trong các mạng trong tương lai (tất nhiên, về hành vi trung thực). Các nút hoạt động trong hệ sinh thái Chainlink ngày nay sẽ tham gia vào việc này cảm thấy có lợi thế hơn người mới trong việc kiếm thêm phí Chainlink dịch vụ trở nên sẵn có. Lợi thế này áp dụng cho các nhà khai thác mới cũng như các công ty công nghệ đã có danh tiếng; ví dụ: T-Systems, một công ty truyền thống nhà cung cấp công nghệ (công ty con của Deutsche Telekom) và Kraken, một công ty tập trung lớn Exchange, đã thiết lập sự hiện diện sớm trong hệ sinh thái Chainlink [28, 143]. Sự tham gia như vậy của các nút oracle trong các cơ hội trong tương lai có thể được coi là chính nó như một loại FFO đầu cơ và do đó tạo thành một dạng cổ phần trong Chainlink mạng. 9.6.3 Danh tiếng bên ngoài IIF như chúng tôi đã mô tả, nó có thể hoạt động trong một mạng có biệt danh hoàn toàn các nhà điều hành, tức là không tiết lộ những người hoặc các thực thể trong thế giới thực có liên quan. Tuy nhiên, một yếu tố quan trọng tiềm tàng đối với việc người dùng lựa chọn nhà cung cấp là bên ngoài. danh tiếng. Khi nói đến danh tiếng bên ngoài, chúng tôi muốn nói đến nhận thức về độ tin cậy gắn liền với danh tính trong thế giới thực chứ không phải là bút danh. Rủi ro danh tiếng gắn liền với danh tính trong thế giới thực có thể được xem như một hình thức khuyến khích ngầm. Chúng tôi xem danh tiếng thông qua lăng kính của IIF, tức là theo nghĩa kinh tế học mật mã, như một phương tiện để thiết lập hoạt động đa nền tảng có thể được đưa vào ước tính FFO. Lợi ích của việc sử dụng danh tiếng bên ngoài làm yếu tố ước tính FFO, trái ngược với với liên kết biệt danh, là danh tiếng bên ngoài liên kết hiệu quả hoạt động không chỉ với các hoạt động hiện tại của nhà điều hành cũng như các hoạt động trong tương lai. Ví dụ, nếu mang tiếng xấu gắn liền với một cá nhân, nó có thể làm hoen ố doanh nghiệp tương lai của người đó. Nói cách khác, danh tiếng bên ngoài có thể nắm bắt được phạm vi FFO rộng hơn so với bút danh hồ sơ hoạt động, vì tác động của hành vi sai trái gắn liền với một người hoặc tổ chức công ty khó trốn thoát hơn công ty liên quan đến hoạt động dưới danh nghĩa. Chainlink tương thích với các công nghệ nhận dạng phi tập trung (Phần 4.3) có thể cung cấp hỗ trợ cho việc sử dụng danh tiếng bên ngoài trong IIF. Những công nghệ như vậy có thể xác nhận và do đó giúp đảm bảo tính xác thực của các nhà khai thác trong thế giới thực được khẳng định danh tính.19 9.6.4 Mở phân tích IIF IIF, như chúng tôi đã lưu ý, nhằm mục đích cung cấp các công cụ và dữ liệu nguồn mở đáng tin cậy cho phân tích khuyến khích ngầm. Mục tiêu là cho phép các nhà cung cấp trong cộng đồng để phát triển các phân tích phù hợp với nhu cầu đánh giá rủi ro của các bộ phận khác nhau trong Chainlink cơ sở người dùng. 19Thông tin xác thực danh tính phi tập trung cũng có thể, nếu muốn, tô điểm cho các bút danh bằng các tên đã được xác thực thông tin bổ sung. Ví dụ: về nguyên tắc, người vận hành nút có thể sử dụng thông tin xác thực đó để chứng minh rằng đó là công ty Fortune 500 mà không tiết lộ đó là công ty nào.Một lượng dữ liệu lịch sử đáng kể liên quan đến doanh thu và hiệu suất của các nút nằm trên chuỗi ở dạng có độ tin cậy cao, không thể thay đổi. Tuy nhiên, mục tiêu của chúng tôi là cung cấp dữ liệu toàn diện nhất có thể, bao gồm dữ liệu về các hành vi chỉ có thể nhìn thấy được chuỗi, chẳng hạn như hoạt động Báo cáo Off-Chain (OCR) hoặc DON. Những dữ liệu như vậy có khả năng hãy đồ sộ. Cách tốt nhất để lưu trữ và đảm bảo tính toàn vẹn của nó, tức là bảo vệ nó khỏi chúng tôi tin rằng việc giả mạo sẽ được thực hiện với sự trợ giúp của DONs, sử dụng các kỹ thuật được thảo luận trong Phần 3.3. Một số khuyến khích phù hợp với các hình thức đo lường trực tiếp, chẳng hạn như staking tiền gửi và FFO cơ bản. Những thứ khác, chẳng hạn như FFO đầu cơ và danh tiếng, khó bị ảnh hưởng hơn. đo lường một cách khách quan, nhưng chúng tôi tin rằng các dạng dữ liệu hỗ trợ, bao gồm sự phát triển lịch sử của hệ sinh thái Chainlink, số liệu về danh tiếng trên mạng xã hội, v.v., có thể hỗ trợ các mô hình phân tích IIF ngay cả đối với các yếu tố khó định lượng hơn này. Chúng ta có thể tưởng tượng rằng DON chuyên dụng phát sinh đặc biệt để giám sát, xác thực và ghi lại dữ liệu liên quan đến bản ghi hiệu suất ngoài chuỗi của các nút, cũng như các dữ liệu khác được sử dụng trong IIF, chẳng hạn như thông tin nhận dạng được xác thực. Những DON này có thể cung cấp dữ liệu IIF thống nhất, có độ tin cậy cao cho bất kỳ nhà cung cấp phân tích nào phục vụ cộng đồng Chainlink. Họ cũng sẽ cung cấp một bản ghi vàng đưa ra tuyên bố của các nhà cung cấp phân tích được cộng đồng xác minh độc lập. 9,7 Kết hợp tất cả lại với nhau: Khuyến khích người vận hành nút Tổng hợp các cuộc thảo luận của chúng tôi ở trên về các ưu đãi rõ ràng và tiềm ẩn đối với các nhà khai thác nút cung cấp cái nhìn toàn diện về cách mà các nhà khai thác nút tham gia và hưởng lợi từ mạng Chainlink. Theo hướng dẫn khái niệm, chúng tôi có thể biểu thị tổng tài sản đang bị đe dọa bằng Chainlink nhất định toán tử nút $S ở dạng thô, cách điệu như: \(S ≈\)D + \(F + \)FS + $R, ở đâu: • $D là tổng hợp của tất cả cổ phần được ký gửi rõ ràng trên tất cả các mạng trong đó người điều hành tham gia; • $F là giá trị hiện tại ròng của tổng hợp tất cả FFO trên tất cả các mạng trong mà nhà điều hành tham gia; • $FS là giá trị hiện tại ròng của FFO đầu cơ của nhà điều hành; và • $R là giá trị danh tiếng của nhà điều hành bên ngoài hệ sinh thái Chainlink có thể bị nguy hiểm do hành vi sai trái được xác định trong các nút oracle của nó. Mặc dù phần lớn chỉ mang tính khái niệm, nhưng sự bình đẳng sơ bộ này cho thấy một cách hữu ích rằng có rất nhiều yếu tố kinh tế ủng hộ hiệu suất có độ tin cậy cao của các nút Chainlink. Tất cả những yếu tố này ngoài $D đều có trong mạng Chainlink ngày nay.9,8 Chu kỳ đạo đức của an ninh kinh tế Sự kết hợp giữa tác động siêu tuyến tính staking với việc thể hiện các khoản thanh toán phí vì cơ hội phí trong tương lai (FFO) trong IIF có thể dẫn đến cái mà chúng ta gọi là chu kỳ đạo đức về an ninh kinh tế trong mạng oracle. Đây có thể coi là một loại hình kinh tế về quy mô. Khi tổng số tiền được bảo đảm bởi một mạng cụ thể tăng lên, số lượng số cổ phần bổ sung cần có để tăng thêm một lượng cố định về an ninh kinh tế sẽ giảm đi chi phí trung bình cho mỗi người dùng. Do đó, về mặt phí, người dùng tham gia sẽ rẻ hơn một mạng lưới đã tồn tại hơn là đạt được mức tăng trưởng kinh tế mạng tương tự bảo mật bằng cách tạo ra một mạng mới. Điều quan trọng là việc thêm mỗi người dùng mới sẽ làm giảm chi phí dịch vụ cho tất cả người dùng trước đây của mạng đó. Với một cấu trúc phí cụ thể (ví dụ: tỷ suất lợi nhuận cụ thể trên số tiền đặt cược), nếu tổng phí mà mạng kiếm được tăng lên, điều này sẽ khuyến khích dòng tiền bổ sung tham gia vào mạng để bảo mật nó ở mức cao hơn. Cụ thể, nếu tổng số cổ phần một nút riêng lẻ có thể giữ trong hệ thống bị giới hạn, sau đó khi thanh toán phí mới vào hệ thống, tăng FFO của nó, số lượng nút n sẽ tăng lên. Nhờ có tác động siêu tuyến tính staking của thiết kế hệ thống khuyến khích của chúng tôi, an ninh kinh tế của hệ thống sẽ tăng nhanh hơn n, ví dụ như n2 trong cơ chế chúng ta phác họa ở Phần 9.4. Kết quả là, chi phí trung bình cho an ninh kinh tế - tức là lượng cổ phần đóng góp một đô la an ninh kinh tế – sẽ giảm. Do đó, mạng có thể tính phí người dùng của nó phí thấp hơn. Giả sử rằng nhu cầu về dịch vụ oracle co giãn (xem ví dụ: [31] để biết thông tin tóm tắt giải thích), nhu cầu sẽ tăng lên, tạo ra phí bổ sung và FFO. Chúng tôi minh họa điểm này bằng ví dụ sau. Ví dụ 5. Vì tính bảo mật kinh tế của mạng oracle với sự khuyến khích của chúng tôi kế hoạch là \(dn2 for stake \)dn, an ninh kinh tế được đóng góp bởi một đô la cổ phần là n và do đó chi phí trung bình trên mỗi đô la của an ninh kinh tế—tức là số lượng cổ phần đóng góp vào một đô la an ninh kinh tế - là 1/n. Hãy xem xét một mạng lưới trong đó các khuyến khích kinh tế bao gồm toàn bộ FFO, có giới hạn ở mức \(d ≤\)10K mỗi nút. Giả sử mạng có n = 3 nút. Khi đó chi phí trung bình mỗi đô la an ninh kinh tế là khoảng 0,33 đô la. Giả sử tổng FFO của mạng tăng lên trên \(30K (e.g., to \)31K). Cho giới hạn trên FFO mỗi nút, mạng sẽ tăng lên (ít nhất) n = 4. Bây giờ chi phí trung bình mỗi đô la an ninh kinh tế giảm xuống còn khoảng 0,25 đô la. Chúng tôi minh họa chu trình tốt đẹp đầy đủ của an ninh kinh tế trong các mạng oracle một cách sơ đồ trong Hình 18. Chúng tôi nhấn mạnh rằng chu kỳ lành mạnh của an ninh kinh tế bắt nguồn từ hiệu ứng người dùng gộp phí của họ. Đó là FFO tập thể của họ hoạt động vì lợi ích lớn hơn quy mô mạng và do đó an ninh tập thể lớn hơn. Chúng tôi cũng lưu ý rằng chu kỳ đạo đức của an ninh kinh tế hoạt động có lợi cho DON đạt được sự bền vững về tài chính. Một lần đã tạo, DON đáp ứng nhu cầu của người dùng sẽ tăng lên đến mức mà tại đó doanh thu từ phí vượt quá chi phí hoạt động cho oracle nút.

Revenue earned by Chainlink nodes on a single ETH-USD data feed showing correlation with price volatility

Schematic of Chainlink staking scheme with alerting showing watchdog escalation and penalty mechanisms

Schematic of the virtuous cycle of Chainlink staking showing how user fees drive security and value capture

Hình 18: Sơ đồ chu trình đạo đức của Chainlink staking. Phí sử dụng tăng thanh toán cho mạng oracle 1⃝ khiến mạng này phát triển, dẫn đến tăng trưởng về mặt kinh tế an ninh 2⃝. Sự tăng trưởng siêu tuyến tính này hiện thực hóa tính kinh tế theo quy mô trong mạng Chainlink 3⃝. Cụ thể, nó có nghĩa là giảm chi phí trung bình của an ninh kinh tế, tức là, đảm bảo kinh tế trên mỗi đô la phát sinh từ việc thanh toán phí hoặc các nguồn cổ phần khác tăng lên. Chi phí thấp hơn, được chuyển tới người dùng, kích thích nhu cầu tăng lên đối với oracle dịch vụ 4⃝. 9,9 Các yếu tố bổ sung thúc đẩy tăng trưởng mạng lưới Khi hệ sinh thái Chainlink tiếp tục mở rộng, chúng tôi tin rằng sức hấp dẫn của nó đối với người dùng và tầm quan trọng của cơ sở hạ tầng đối với nền kinh tế blockchain sẽ tăng tốc. Giá trị do mạng oracle cung cấp là siêu tuyến tính, nghĩa là giá trị này tăng nhanh hơnhơn kích thước của mạng. Sự tăng trưởng về giá trị này xuất phát từ cả tính kinh tế theo quy mô—hiệu quả chi phí cho mỗi người dùng lớn hơn khi khối lượng dịch vụ tăng lên—và hiệu ứng mạng—sự gia tăng tiện ích mạng khi người dùng áp dụng DON rộng rãi hơn. Vì smart contract hiện tại tiếp tục nhận được nhiều giá trị được bảo đảm hơn và hoàn toàn mới smart contract các ứng dụng được thực hiện nhờ nhiều dịch vụ phi tập trung hơn, tổng cộng việc sử dụng và tổng phí trả cho DON sẽ tăng lên. Tăng các khoản phí trong biến dịch thành phương tiện và động lực để tạo ra nhiều dịch vụ phi tập trung hơn, dẫn đến một chu kỳ đạo đức. Chu kỳ đạo đức này giải quyết vấn đề con gà và quả trứng quan trọng vấn đề trong hệ sinh thái lai smart contract: Các tính năng smart contract đổi mới thường yêu cầu các dịch vụ phi tập trung chưa tồn tại (ví dụ: các thị trường DeFi mới thường yêu cầu nguồn cấp dữ liệu mới) nhưng vẫn cần có đủ nhu cầu kinh tế để tồn tại. Việc gộp phí theo nhiều smart contract khác nhau cho DON hiện tại sẽ báo hiệu nhu cầu về các dịch vụ phi tập trung bổ sung từ cơ sở người dùng ngày càng tăng, dẫn đến sự sáng tạo của chúng bởi DONs và sự hỗ trợ liên tục của smart contracts kết hợp mới và đa dạng. Tóm lại, chúng tôi tin rằng sự tăng trưởng về an ninh mạng được thúc đẩy bởi đạo đức các chu kỳ trong cơ chế Chainlink staking minh họa cho các mô hình tăng trưởng lớn hơn mạng Chainlink có thể giúp mang lại nền kinh tế trực tuyến cho phi tập trung dịch vụ.

Diagram showing how concentrated alerting rewards amplify the cost for a briber attempting to corrupt the oracle network

経済学と暗号経済学

Chainlink ネットワークが分散信頼モデル内で強力なセキュリティを実現するには、 ノードが集合的に正しい動作を示すことが重要です。つまり、ノードが遵守していることを意味します。 ほとんどの場合、正確に DON プロトコルに準拠します。このセクションでは、アプローチについて説明します 経済的インセンティブ、別名暗号経済によってそのような行為の強制を支援すること インセンティブ。 これらのインセンティブは、明示的と暗黙的、実現化の 2 つのカテゴリに分類されます。 それぞれ staking および将来の手数料機会 (FFO) を通じて。 ステーキング: Chainlink でのステーキングには、他の blockchain システムと同様に、ネットワーク参加者、つまり oracle ノードが関与し、ロックされた資金を LINK token の形式で預け入れます。これら ファンド（ステークまたは明示的ステークとも呼ばれます）は、明示的なインセンティブです。彼らは ノードの障害または不正行為により、権利が剥奪される可能性があります。 blockchain のコンテキストでは、 この手順は、多くの場合、スラッシュと呼ばれます。 ただし、Chainlink の oracle ノードによるステーキングは、staking とは根本的に異なります。 validators による、権限のない blockchains です。バリデーターは、トランザクションを曖昧にしたり、敵対的に順序付けたりすることで不正行為を行う可能性があります。 基礎となるコンセンサスプロトコル 15ユーザーはメモリプール内のトランザクションを置き換えることができるため、マイニングされたトランザクションと DON によって送信されたトランザクションが正しく対応するように注意する必要があります。ただし、権限のない blockchain は、厳格なブロック検証ルールと暗号化プリミティブを使用して、validator が無効なブロックを生成するのを防ぎます。対照的に、 プログラムによる保護では、不正な oracle ネットワークによる生成を防ぐことはできません。 無効なレポート。その理由は、2 つのタイプのシステム間の重要な違いです。blockchains のトランザクション検証は内部一貫性の特性であるのに対し、正確性は内部一貫性の特性です。 blockchain に関する oracle のレポートは、外部データ、つまりオフチェーン データのプロパティです。 私たちは、Chainlink ネットワークベースの予備的な staking メカニズムを設計しました。 外部データを利用する可能性がある oracle ノード間の対話型プロトコル上で。これ このメカニズムは、明示的な報酬を使用して、正しい行動に対する金銭的インセンティブを生み出します。 ペナルティ（斬り）。経済的な仕組みなので、ノードの発生を防ぐことができます。 攻撃者が金融リソースを使用してノードを破壊することによる破壊 賄賂。 (そのような敵対者は非常に一般的であり、例えば、協力しているノードにまで広がります。 彼らの集団的な不正行為から価値を引き出す。） 私たちが設計した Chainlink staking メカニズムには、いくつかの強力で斬新な機能が備わっています。 16 そのような主な機能は、超線形 staking 衝撃 (具体的には 2 次) です。 敵は、ノードが預けた資金を大幅に超えるリソースを持っている必要があります。 メカニズムを破壊するために。当社の staking メカニズムは、同様のシステムでこれまで考えられていたよりも強力な敵対者に対する保護も提供します。 ノードの将来の行動に条件を付けて賄賂を生み出すことができる敵。さらに、DECO などの Chainlink ツールが staking の強化にどのように役立つかについて説明します。 ノードの動作に問題がある場合に正しい判断を容易にすることで、このメカニズムを強化します。 将来の手数料機会 (FFO): 両方の PoW の許可のない blockchains そして、PoS の多様性 - 今日、暗黙的なインセンティブと呼ばれるものに大きく依存しています。これらは 明示的な報酬からではなく、誠実な行動に対する経済的インセンティブ。 プラットフォームへの参加自体から。たとえば、Bitcoin マイナー コミュニティは、信頼を損なうリスクがあるため、51% 攻撃を仕掛けることに対してインセンティブが与えられています。 Bitcoin、その価値を低下させ、その結果、彼らの集団の価値を損なう 鉱山インフラへの資本投資 [150]。 Chainlink ネットワークは、ここで言及する同様の暗黙的なインセンティブから恩恵を受けています。 将来の手数料機会 (FFO) として。強力なパフォーマンス履歴を持つ Oracle ノード、または 評判によってユーザーから料金が発生します。 oracle ノードによる不正な動作は将来を危険にさらします 手数料の支払いが発生するため、潜在的な可能性の観点からノードに機会費用のペナルティが課せられます。 ネットワークへの参加を通じて得られる収益。明示的なステークから類推すると、 FFO は、暗黙の利害関係、つまり誠実な行動に対するインセンティブの一種とみなされる場合があります。 それは、プラットフォームに対する信頼を維持するという共通の利益から生まれます。 ノードオペレーターのビジネスは、ノードオペレーターの良好なパフォーマンスと評判に依存します。 ネットワーク。このインセンティブは Chainlink ネットワークに固有のものですが、明示的には表現されていません プロトコル。 Bitcoin では、前述のようにマイニング操作の価値を維持します 16ここで説明するstakingメカニズムは、現時点では正しいレポートの配信を強制することのみを目的としています。 oracle ネットワークによる。将来的には、多くの機能が正しく実行されるように拡張する予定です。 DONs が提供するその他の機能。同様に、暗黙のステークの一形態としてみなされる可能性があります。 FFO はすでに Chainlink に存在し、ネットワークのセキュリティ保護に役立つことを強調します。 今日。 Chainlink のさらなる開発における私たちの主な貢献は、FFO などの暗黙的なインセンティブを評価するための原則に基づいた経験に基づいたアプローチです。 これを暗黙的インセンティブ フレームワーク (IIF) と呼んでいます。次のような数量を推定するには、 ノードの将来の手数料の機会に応じて、IIF は引き続き包括的な料金を活用します。 Chainlink ネットワークによって蓄積されたパフォーマンスと支払いのデータ。そのような推定 ノードのインセンティブを反映する staking システムの IIF ベースのパラメータ化が可能になります 現在のヒューリスティック モデルや静的モデルよりも高い精度で実現できます。 正しい oracle ノードに対する 2 つの主な経済的インセンティブを要約すると、 開発中の Chainlink ネットワークでの動作は次のようになります。 • ステーキング（賭け金） ああ 明示的なインセンティブ • 将来の手数料機会 (FFO) ああ 暗黙のインセンティブ これら 2 つの形式のインセンティブは補完的です。 Oracle ノードは同時に Chainlink staking プロトコルに参加し、からの継続的な収益源を享受します。 ユーザーの継続的な善良な行動から、全員が利益を得ることができます。したがって、両方のインセンティブが oracle ネットワークによって提供される暗号経済セキュリティに貢献します。さらに、 2 つのインセンティブは相互に強化したり、相互にトレードしたりすることができます。たとえば、 実績履歴も収入源もない新しいoracleオペレーターは、 誠実な行動を保証するための大量のリンクがユーザーを引き付ける そして手数料。逆に、確立された oracle オペレーターは、長くて比較的障害が少ない パフォーマンス履歴により、大規模なユーザー ベースから多額の料金が請求される可能性があるため、 暗黙のインセンティブとして FFO をより重視します。 一般に、ここで検討するアプローチは、指定された量の oracle-ネットワークを目的としています。 合理的な目的のためにChainlinkで可能な限り最大の経済的インセンティブを生み出すためのリソース エージェント、つまり財務的効用を最大化するノードは誠実に行動する必要があります。もう一つ入れて つまり、目標は、敵対者が攻撃するために必要な財務リソースを最大化することです ネットワークが正常に接続されました。 staking プロトコルを数学的に適切に定式化することにより、 私たちは、経済安全保障を定義し、また IIF を使用して、経済安全保障の強さを測定することを目指しています。 Chainlink のインセンティブをできるだけ正確に。依存契約の作成者は、 そうすれば、oracle ネットワークが条件を満たしているかどうかを強い自信を持って判断できるようになります。 必要な暗号経済セキュリティのレベル。 経済安全保障の好循環: このセクションで説明するインセンティブ、staking と FFO は、セキュリティの強化を超えた影響を及ぼします。 DON秒。彼らは、私たちが経済安全保障の好循環と呼ぶものを誘発すると約束しています。 超線形 staking の影響 (およびその他の規模の経済) により、運用効率が低下します。 DON のセキュリティが増大するにつれてコストが増加します。低コストにより、DON に追加のユーザーが集まります。追加料金の支払い。手数料支払いの増加は引き続き成長を促進します。 ネットワークを構築し、好循環を永続させます。 私たちは、経済安全保障の好循環はほんの一例にすぎないと信じています。 特に規模の経済性とネットワーク効果については、このセクションで後ほど説明します。 セクションの構成: ステーキングは、注目すべき技術的および概念的な課題を提示します。 斬新な機能を備えた機構を設計しました。したがって、ステーキングは次のようになります。 このセクションの主な焦点は次のとおりです。 この文書で紹介する staking アプローチの概要をセクション 9.1 で説明し、続いてセクション 9.2 ～ 9.5 で詳細に説明します。 IFFを紹介します セクション9.6に記載されています。 Chainlink ネットワーク インセンティブの概要をセクション 9.7 に示します。 セクション 9.8 では、私たちが提案する staking アプローチが oracle ネットワークにもたらすことができる経済安全の好循環について説明します。最後に、その他の可能性について簡単に説明します。 セクション 9.9 の Chainlink ネットワークの成長を促進する効果があります。 9.1 ステーキングの概要 ここで紹介する staking メカニズム設計には、上で述べたように、oracle ノード間の対話型プロトコルが含まれており、 外部データのレポート。ステーキングは、合理的な oracle ノードからの誠実な動作を保証することを目的としています。したがって、staking プロトコルを攻撃する敵をモデル化できます。 賄賂: 敵対者の戦略は、金銭的インセンティブを利用して oracle ノードを破壊することです。 敵対者は、改ざんに成功することで将来的に資金を得る可能性がある oracle レポートを使用して、たとえば、結果として得られた利益を破損したノードと共有することを提案します。 私たちは staking メカニズム設計において、次の 2 つの野心的な目標を同時に目指しています。 1. 強力な敵に対抗する: staking メカニズムは、 oracle ネットワークは、複雑な攻撃を行うことができる広範なクラスの敵に対して対抗します。 賄賂を提供する見込賄賂を含む、条件付き賄賂戦略 事後的に身元が判明したoracleに（例：賄賂を提供するなど） oracle は高優先度のアラート用にランダムに選択されます)。他のoracleデザインは 現実的な攻撃の全機能を持たない狭い範囲の攻撃を検討してきました。 敵対者、私たちが知る限り、私たちが導入する敵対的メカニズム ここは、広範な賄賂戦略に明示的に取り組み、その結果を示した最初の企業です。 このモデルの抵抗。私たちのモデルは、攻撃者以外のノードが （正直ではなく）経済的に合理的であり、私たちは、 通常の使用法では法外に高価だが入手可能な信頼できる情報源 意見の相違がある場合には（以下でさらに説明します）。 2. 超線形 staking 効果の達成: 私たちの目的は、合理的なエージェントで構成される oracle ネットワークがレポートを確実に実行できるようにすることです。 正直なところ、超線形の予算を持つ攻撃者の存在下でもです。ネットワーク全体によって預けられた賭け金の合計に相当します。既存の staking システムでは、 n 個のノードのそれぞれが $d を賭けると、攻撃者は要求に応じて信頼できる賄賂を発行することができます。 ノードは、わずかに高い金額の支払いと引き換えに不正な行為を行う \(d to each node, using a total budget of about \)dn。これはすでに高いハードルです 攻撃者は、次の預金を合わせた程度の流動的な予算を持っている必要があります。 ネットワーク内のすべての関係者。私たちの目標は、さらに強力な経済安全保障です。 このすでに大きなハードルよりも。私たちは最初のstakingシステムを設計することを目指しています n 単位の超線形予算で一般攻撃者のセキュリティを実現できます。 以下で説明するように、実際的な考慮事項の影響は小さくなる可能性がありますが、 私たちの予備設計では、敵対的な予算要件を超える予算が達成されます。 $dn2/2、つまり n で 2 次スケーリングし、賄賂をほとんど非現実的にする ノードが中程度の金額のみをステーキングする場合。 これら 2 つの目標を達成するには、インセンティブ設計の革新的な組み合わせが必要です そして暗号化。 重要なアイデア: 私たちの staking アプローチは、ウォッチドッグ優先度と呼ばれる考え方に基づいています。 Chainlink oracle ネットワークによって生成され、信頼するコントラクトに送信されるレポート （例えば、資産価格について）参加ノードによって提供された個々のレポートから（例えば、中央値を取ることによって）集約されます。通常はサービス レベル アグリーメント (SLA) レポートの許容偏差範囲、つまりノードのレポートがどこまで許容できるかを指定します。 集計レポートからの逸脱、および集計がどの程度まで許容されるべきか 正しいとみなされる真の値から逸脱していること。 staking システムでは、特定のレポート ラウンドで、各 oracle ノードが次のように機能します。 ウォッチドッグは、集計レポートが正しくないと思われる場合にアラートを生成します。それぞれに レポート ラウンドでは、各 oracle ノードには、公開優先度が割り当てられます。 アラート (存在する場合) が処理される順序。私たちの仕組みは報酬を目的としています これは、アラートを発生させる最も優先度の高いウォッチドッグが、 障害のあるノードの預金を没収することで得られる報酬全体。 当社の staking システム設計には 2 つの層が含まれます。最初のデフォルト層と 2 番目の層です。 バックストップ層。最初の層は oracle ネットワーク自体であり、n 個のノードのセットです。 (簡単にするために、 n は奇数であると仮定します。) 大多数のノードが誤った値を報告すると、ノードのウォッチドッグが 第 1 層には、警告を発する強い動機が与えられています。アラートが発生した場合、レポートは その後、ネットワークの決定は第 2 層にエスカレートされます。これは、ネットワーク サービス レベル アグリーメントでユーザーが指定できる、高コストで信頼性が最大のシステムです。 これは、たとえば、強力なノードのみで構成されるシステムである可能性があります。 過去の信頼性スコア、またはそれよりも oracle 秒が桁違いに多いスコア 最初の層。さらに、セクション 9.4.3 で説明したように、DECO または Town Crier はサービスを提供できます。 第 2 段階での効率的かつ最終的な判決を確保するための強力なツールとして機能します。 簡単にするために、この第 2 層システムが正しいレポートに到達すると仮定します。 値。 すべてのレポートを生成するために第 2 層に依存するだけでも魅力的に見えるかもしれませんが、 私たちの設計の利点は、そのセキュリティ特性を一貫して達成できることです。一般的なケースでは、第 2 層システムの運用コストのみを支払います。 第一層システム。 ウォッチドッグの優先順位により、次のように超線形 staking の影響が生じます。 第 1 層 oracle ネットワークが誤った結果と多数のウォッチドッグ ノードを出力します アラートが発生すると、staking インセンティブ メカニズムにより、最も優先度の高いウォッチドッグに報酬が与えられます。 (大多数の) 不正動作をしているノードのデポジットから $dn/2 を超える額が引き出されます。の したがって、報酬総額はこの 1 人の監視者の手に集中します。 敵対者が潜在的な監視者に約束しなければならない最低限の事項を決定する 警戒しないように奨励します。私たちのメカニズムでは、すべての oracle が確実に より優先度の高い番犬が賄賂を受け取った場合、番犬として行動するチャンス （そして警告しないことを選択した）、したがって、敵対者は以上の賄賂を提供する必要があります。 アラートの発生を防ぐために、すべてのノードに $dn/2 を追加します。 n 個のノードがあるため、 敵対者が賄賂を成功させるために必要な予算は、dn2/2 ドルを超えます。 は、ネットワーク内のノード数 n の二次関数です。 9.2 背景 staking に対する私たちのアプローチは、ゲーム理論とメカニズムの分野の研究に基づいています。 デザイン (MD) (教科書の参照については、[177] を参照)。ゲーム理論は数学的には 戦略的相互作用の正式な研究。この文脈では、ゲームはそのようなモデルです。 通常は現実世界において、利用可能なアクションのセットを体系化したインタラクション。 プレイヤーとして知られるゲームの参加者。ゲームでは、得られる報酬も指定されます 個々のプレイヤーによる報酬 - プレイヤーが選択したアクションと 他のプレイヤーの行動。おそらくゲームで研究されたゲームの最もよく知られた例 この理論は囚人のジレンマ [178] です。ゲーム理論家は通常、次のことを理解することを目指しています。 特定のゲームで表現される均衡 (存在する場合)。平衡というのは、 どのプレイヤーもより高いレベルを獲得できないような一連の戦略 (各プレイヤーに 1 つ) 戦略から一方的に逸脱することで利益を得る。 一方、メカニズムデザインは、次のようなインセンティブをデザインする科学です。 インタラクション (およびそれに関連するゲーム) の平衡には、望ましい特性があります。 MD はゲーム理論の逆とみなされるかもしれません: ゲームにおける標準的な質問 理論は、「インセンティブとモデルが与えられた場合、均衡はどうなるでしょうか?」というものです。 MDでは、 代わりに問題となるのは、「どのようなインセンティブがゲームに望ましい均衡をもたらすのか?」ということです。 メカニズム設計者の典型的な目標は、「インセンティブと互換性のある」メカニズムを作成することです。これは、メカニズムへの参加者 (例: オークションやその他の情報) を意味します。 引き出しシステム [228]) は、ある事柄について真実を報告するよう奨励されます (例: どのように 彼らは特定のアイテムを高く評価します）。ヴィックリー（セカンドプライス）オークションはおそらく 参加者が非公開入札を提出する、最もよく知られたインセンティブ互換メカニズム アイテムの場合、最高額入札者がアイテムを落札しますが、2 番目に高い価格を支払います [214]。クリプトエコノミクスは、暗号を利用するドメイン固有の形式の MD です。 分散システム内で望ましい均衡を生み出すための技術。 贈収賄と共謀は、MD の分野全体に重大な問題を引き起こします。ほとんどすべてのメカニズムは、側の契約として定義される共謀が存在すると機能しません。メカニズムに参加する当事者間 [125、130]。外部の関係者が新たなインセンティブをゲームに導入する贈収賄は、さらに困難な問題を引き起こします 共謀よりも。共謀はゲーム間の贈収賄の特殊なケースとみなされる可能性がある 参加者。 ブロックチェーン システムは、多くの場合、金銭 (暗号通貨ベース) の利益を伴うゲームとして概念化できます。簡単な例は、Proof-of-Work マイニングです。マイナーにはアクション スペースがあります。 ここでは、ブロックのマイニングに使用するhashレートを選択できます。マイニングの報酬は、保証されたマイナスの報酬 (電気と設備のコスト) に確率的報酬を加えたものです。 他のアクティブなマイナーの数に応じたプラスの報酬 (マイニング補助金) [106、172] および取引手数料。 SchellingCoin [68] のようなクラウドソースの oracle は別の例です。アクション スペースは、oracle が送信できる一連のレポートです。 報酬は、oracle メカニズムによって指定された報酬です。たとえば、支払いは状況に応じて異なります。 oracle のレポートが他のレポートの中央値にどの程度近いか [26、68、119、185]。 ブロックチェーン ゲームは、共謀や贈収賄攻撃の絶好の機会を提供します。確かに、 smart contracts はそのような攻撃を容易にすることさえあります [96、165]。おそらく最もよく知られているのは クラウドソーシング oracles に対する贈収賄攻撃は、p-plus-epsilon 攻撃 [67] です。この攻撃 これは、プレーヤーがブール値のレポート (つまり、偽または真) を送信し、同意した場合に p が与えられるというシェリングコインのようなメカニズムのコンテキストで発生します。 過半数の提出。 p プラス イプシロン攻撃では、攻撃者は確実に次のことを約束します。 たとえば、過半数の提出が正しい場合にのみ、偽の投票に対してユーザーに $p + ϵ を支払います。 その結果、すべてのプレイヤーが虚偽の報告をするよう動機づけられる均衡が生まれます。 他のプレイヤーが何をしているかに関係なく。その結果、賄賂はノードを誘導することができます。 実際に賄賂を支払わずに虚偽の報告をするという約束の賄賂によって（！）。 ただし、oracle、特にクラウドソーシングではない oracle に関連した他の賄賂戦略の検討は、かなり弱い敵対者に限定されています。 モデル。たとえば、PoW 環境では、研究者は結果に応じた条件を研究しました。 賄賂、つまり、対象メッセージが検閲に成功し、検閲されなかった場合にのみ支払われる賄賂。 個々のマイナーのアクションに関係なく、ブロック内に表示されます [96、165]。場合によっては ただし、p-plus-epsilon 攻撃以外では、oracle 件の攻撃のみが認識されています。 賄賂を受け取る者が条件付きで賄賂を送るという、厳密に限定された贈収賄モデル。 結果としての結果ではなく、個々のプレイヤーの行動です。 ここでは、インセンティブを維持する情報引き出しメカニズムの設計をスケッチします。 次のサブセクションで説明するように、強力な敵対的モデルでも互換性があります。 9.3 モデリングの仮定 このサブセクションでは、プレイヤーの行動と能力をモデル化する方法について説明します。 私たちのシステム、特に第 1 層 oracle ノード、第 2 層のノード (判定) レイヤーと敵。9.3.1 第一層インセンティブ モデル: 合理的なアクター 多くの blockchain システムは、ある程度の正直者を前提としたセキュリティに依存しています。 参加ノード。ノードは、たとえプロトコルに従った場合でも正直であると定義されます。 そうすることが経済的利益にならない場合。 Proof-of-Work システムは通常、 正直に言うとhashのパワーの大部分が必要ですが、プルーフ・オブ・ステーク・システムでは通常、正直に参加するすべてのステークの2/3以上が必要です。また、次のようなレイヤー2システムでさえも必要です。 仲裁 [141] には、少なくとも 1 人の誠実な参加者が必要です。 staking メカニズムのモデル化では、はるかに弱い仮定を立てます。 (なるように 明確で弱い仮定は、より強力なセキュリティ特性を意味するため、推奨されます。) 敵対者が一部 (少数派) のコントロールを破損していると仮定します。 第 1 層 oracle ノードの一部。残りのノードは正直なエージェントとしてモデル化されません。 しかし、合理的な期待効用最大化手段として。これらのノードは完全に利己的な金銭的インセンティブに従って動作し、期待される金銭的利益をもたらすアクションを選択します。 利益を得る。たとえば、ノードが報酬よりも多額の賄賂を提供された場合、 正直な行動をすれば、賄賂を受け取ります。 敵対的ノードに関する注意: 共通の信頼モデリングに従って、 分散型システムでは、すべてのノードが合理的である、つまり、ノードを最大化しようとしていると仮定します。 悪意のある敵によって制御されるのではなく、純収益が向上します。しかし、私たちの主張は— 特に超線形または二次 staking 衝撃 - 漸近的に提供されるホールド 敵対的に制御されるノードのセットは最大でも (1/2 −c)n であること (肯定的な場合) 定数 ｃ． 9.3.2 第 2 段階の裁定モデル: 仮定による正しさ セキュリティの実現に役立つ staking メカニズムの重要な機能を思い出してください。 合理的なノードに対するのは、その 2 層目のシステムです。 私たちが提案する staking メカニズムでは、oracle は次のことを示すアラートを生成する可能性があります。 メカニズムの出力が正しくないと考えられます。アラートにより高い信頼が得られます 第 2 層システムがアクティブ化され、正しい結果が報告されます。したがって、主要なモデリングは 私たちのアプローチの要件は、正しい判決、つまり、政府による正しい報告です。 第二層システム。 私たちの staking モデルは、腐敗せず、信頼性が最も高い信頼性の高い情報源として機能する第 2 層システムを前提としています。このようなシステムは高価で時間がかかる可能性が高いため、 一般的なケースでの使用には不適切です。ただし、均衡の場合、つまり、 第 1 層システムが正しく機能する場合、第 2 層システムは呼び出されません。 代わりに、その存在により、oracle システム全体のセキュリティが強化されます。 信頼性の高いバックストップ。 高信頼で高コストの裁定レイヤーの使用は、控訴プロセスに似ています ほとんどの司法制度の中心です。 oracle のデザインでもすでに一般的になっています。 システム、例: [119, 185]。第 2 層の実現へのアプローチについて簡単に説明します セクション9.4.3のメカニズムに記載されています。私たちの staking プロトコルは、第 2 層システムの想定される正しい判定を信頼できる脅威として使用し、oracle ノードによる正しいレポートを強制します。プロトコル によって識別されるレポートを生成する oracle ノードのステークの一部またはすべてを没収します。 第 2 層システムは正しくありません。これにより、Oracle ノードの誤動作が防止されます。 その結果生じる経済的ペナルティによって。このアプローチは、で使用されているものと風味が似ています。 楽観的な rollup、例: [141, 10]。 9.3.3 敵対的モデル 当社の staking メカニズムは、広範で明確に定義されたクラスの敵に対するセキュリティを実現しながら、真実の情報を引き出すように設計されています。以前の作品を改良しており、 これは、明示的な敵対的モデルを省略するか、敵対者の狭いサブクラス、たとえば、上で説明した p-plus-epsilon 敵対者に焦点を当てるかのいずれかです。私たちの目標は、staking を設計することです。 あらゆる種類の敵に対して正式に証明されたセキュリティを備えたメカニズム 実際に遭遇することになる。 私たちは、敵を固定の (パラメータ化可能な) 予算を持つものとしてモデル化します。 $B.攻撃者は、各 oracle と個別かつ機密に通信できます。 ネットワークを介して、個人oracleに秘密裏に賄賂の支払いを提供することができます。 メカニズムの公的に観察可能な結果次第です。結果を決定する 賄賂には、たとえば、oracle によって報告された金額や、あらゆる公開メッセージが含まれる場合があります。 任意の oracle によってメカニズムに送信され (アラートなど)、他のメカニズムによって報告された値 oracles、およびメカニズムによって出力された値。 無制限の機能を持つ攻撃者に対して安全を確保できるメカニズムはありません。したがって、一部の動作は非現実的または範囲外であると考えられます。攻撃者を想定します 標準の暗号化プリミティブを破ることはできず、上で述べたように、修正された暗号化プリミティブがあります ( 大規模になる可能性があります) 予算 B ドル。さらに、敵が制御していないと仮定します。 oracle ネットワーク内の通信、具体的には実質的に遅延できないこと 第 1 層ノードおよび/または第 2 層ノード間のトラフィック。 (攻撃者がそのような通信を観察できるかどうかは、以下で説明するように、特定のメカニズムによって異なります。) ただし、非公式ではありますが、上で述べたように、敵対者は次の可能性があると想定しています。(1) 腐敗 oracle ノードの一部 (定数 c の (1/2 −c) の一部)、つまり完全制御 (2) 支払いを保証して、希望するノードに賄賂を提供する 上で説明したように、敵対者によって指定された結果に基づいて。 私たちは敵対者の完全な正式なモデルや完全な分類を提供していませんが、 このホワイトペーパーではさまざまな賄賂権限について説明していますが、ここでは賄賂の種類の例を示します。 私たちのモデルには賄賂が含まれます。簡単にするために、oracles がブール値を出力すると仮定します。 正しい値 (w.l.o.g.) が true であり、最終結果が次のように計算されることをレポートします。 smart contract を使用するユーザーによって使用されるこれらのレポートの集合体。賄賂の 目的は、最終結果が不正確、つまり偽になることです。 • 無条件の賄賂: 賄賂は虚偽の報告をした oracle に $b の賄賂を提供します。 • 確率的賄賂: 賄賂は、oracle に対して、一定の確率 q で $b の賄賂を提供します。 それは虚偽の報告をします。• 虚偽の結果を条件とする賄賂: 賄賂は、最終結果が虚偽であることを条件として、虚偽を報告した oracle に $b の賄賂を提供します。 • 警戒条件なしの賄賂: 賄賂は報告するoracleに$bの賄賂を提供します。 アラートが発生しない限り false。 • p-plus-epsilon 賄賂: 賄賂は、虚偽の報告をした oracle に $b の賄賂を提供します。 oracle の大部分が false を報告しない限り。 • 賄賂候補者: 賄賂は、oracle が選択された方に前払いで $b の賄賂を提供します。 ランダム化された役割に対しては false が報告されます。私たちが提案する staking プロトコルでは、すべて ノードは潜在的なウォッチドッグとして機能し、ランダム化を示すことができます。 監視機関の優先事項は、贈収賄の可能性には適さない。多くのproof-of-work、proof-of-stake、および許可されたシステムは、将来の悪影響を受けやすいです。 しかし、贈収賄については、敵対関係においてそれを考慮することの重要性を示しています。 モデルを作成し、staking プロトコルがモデルに対して復元力があることを確認します。付録 E を参照 詳細については。 9.3.4 どれくらいの暗号経済セキュリティがあれば十分ですか? 合理的な攻撃者は、利益が得られる場合にのみ、システムを攻撃するために資金を費やします。 その支出よりも大きい。 したがって、敵対的モデルと提案された staking については、 このメカニズムでは、$B は敵対者が獲得できる潜在的な利益の尺度としてみなされる可能性があります。 oracle ネットワークを破損し、それを引き起こすことで、依存する smart contracts から抽出する 間違ったレポートまたはレポートのセットを生成するため。 oracle ネットワークかどうかを決定する際 目的に応じて十分な程度の暗号経済的セキュリティを提供するため、ユーザーは次のことを行う必要があります。 この観点からネットワークを評価してください。 実際の設定におけるもっともらしい敵対者の場合、$B は一般に次のようになることが予想されます。 smart contracts に依存する総資産よりも大幅に小さい。ほとんどの場合、それは 攻撃者がこれらの資産全体を抽出することは不可能です。 9.4 ステーキングメカニズム: スケッチ ここでは、staking メカニズムの主なアイデアと一般的な構造を示します。 現在検討中です。 プレゼンテーションを容易にするために、単純だが遅いものについて説明します。 (マルチラウンド) プロトコルについては、このサブセクションで説明します。ただし、この計画は非常に危険であることに注意してください。 実用的。このメカニズムによって提供される経済的保証、つまり障害のあるノードに対するペナルティとその結果としてのインセンティブを考慮すると、多くのユーザーは喜んでそうするかもしれません。 報告を楽観的に受け入れます。言い換えれば、そのようなユーザーは、事前にレポートを受け入れることができます。 第二段階による裁定の可能性。 レポートを楽観的に受け入れたくないユーザーは、プロトコルが確立されるまで待つことを選択できます。 実行は、つまり、第 2 層への潜在的なエスカレーションが発生するまで終了します。これ、 ただし、レポートの確認時間が大幅に遅くなる可能性があります。したがって、簡単に説明します図 15: アラートを備えた staking スキームの回路図。この例では、1⃝過半数 のノードが破損または賄賂を受けており、正しい値ではなく誤った値 ˜r を発行しています レポート値 r。ウォッチドッグ ノード 2⃝ は第 2 層委員会にアラートを送信します。 3⃝正しいレポート値 r を決定して出力するため、ノードが破損します。 デポジットは没収され、各 $d がウォッチドッグ ノード 4⃝ に送られます。 多少なりとも高速化 (シングルラウンド) をもたらすいくつかの最適化の概要を説明します。 セクション 9.5 の複雑な設計。 staking メカニズムの最初の層は、基本的な oracle で構成されていることを思い出してください。 ネットワークそのもの。 上で説明したように、私たちのメカニズムの主な構造は、各ラウンドで、 各ノードは、ある程度の優先順位を持って「ウォッチドッグ」として機能することができるため、次のような機能を備えています。 メカニズムが正しい出力ではなく、誤った出力 ˜r に到達した場合にアラートを生成します。 1r。このアラートにより、第 2 層の解決が引き起こされ、正しい解決策が得られると想定されます。 報告する。不正確なレポートを持つノードは、その賭け金が報われるという意味で罰せられます。 切り取られ、監視員に授与された。この基本構造は oracle システムに共通です。 例: [119, 185]。 上で簡単に述べたように、私たちの設計における重要な革新は、すべてのノードが 潜在的なウォッチドッグの順序付けにおいて明確な優先順位が割り当てられます。つまり番犬 優先順位に従って警告する機会が与えられます。ノードに 警告を発することが最優先であり、あらゆる不正行為に対して減額されたデポジット $d が受け取られます。 合計が \(dn/2 = \)d × n/2 を超えるノード。正しくないレポートは、 不良ノードの大部分。したがって、敵は少なくともこの報酬を支払わなければなりません。 任意のノードに賄賂を渡す。したがって、大多数のノードに賄賂を渡すには、敵は報酬を支払わなければなりません。 大多数のノード、つまり厳密には $dn2/2 以上への多額の賄賂。 図 15 に、アラートとウォッチドッグのエスカレーションがどのように機能するかを概略的に示します。9.4.1 メカニズムの詳細 ここでさらに詳しく説明する贈収賄防止システムは、 私たちが建設しようとしている二層構造。私たちの焦点のほとんどは説明にあります 第 1 層ネットワーク (以下、文脈から明らかでない場合は単に「ネットワーク」とします) インセンティブ メカニズムと第 2 段階へのエスカレーション手順を備えています。 以下を担当する n 個の oracle ノードで構成される Chainlink ネットワークを考えてみましょう。 定期的に (例: 1 分に 1 回) ブール値を報告します (例: 市場が BTC の時価総額は ETH の時価総額を上回ります）。 staking メカニズムの一部として、ノード 2 つのデポジットを提供する必要があります: デポジット $d は、意見の相違があった場合には減額される可能性があります。 過半数と監視機関が$dwを預金し、欠陥があった場合には削減の対象となる エスカレーション。ノードは他のノードの送信をコピーできないと仮定します。 セクション 5.3 で説明した commit-reveal スキームを通じて。各ラウンドでは、まずノードが レポートにコミットし、すべてのノードがコミットしたら (またはタイムアウトが経過したら)、 ノードはレポートを公開します。 生成される各レポートについて、すべてのノードにはランダムに選択された 1 から n までのウォッチドッグ優先順位も与えられます。1 が最優先です。この優先順位により、 報酬が 1 人の監視者の手に集中する。すべてのレポートが公開された後、 警告フェーズが続きます。一連の n (同期) ラウンドにわたって、ノードは 優先度 i にはラウンド i で警告する機会があります。 ノードが明らかになった後、メカニズムで考えられる結果を考えてみましょう。 彼らのレポート。ここでもバイナリ レポートを想定し、正しい値が true であると仮定します。 間違っているものは偽です。また、第 1 層メカニズムが次を出力すると仮定します。 最終レポートとしてノードによって出力される多数決値 r。 このメカニズムでは、次の 3 つの結果が考えられます。 • 完全な一致: 最良の場合、ノードは完全に一致しています: すべてのノード が利用可能であり、同じ値 r (true のいずれか) のタイムリーなレポートを提供しています。 または偽）。この場合、ネットワークは r を信頼するコントラクトに転送するだけで済みます。 そして、各ノードにラウンドごとの固定支払い $p を報酬として与えますが、これははるかに少額です $dよりも。 • 部分一致: 一部のノードがオフラインであるか、どの値が正しいかについて意見が一致していない可能性がありますが、ほとんどのノードは true を報告し、 少数派が虚偽の報告をしている。このケースも単純明快です。過半数の値 (true) が計算され、正しいレポート r が生成されます。 r を報告したすべてのノードは、 誤って報告したoracleがデポジットを持っている間、報酬として$pが与えられます たとえば10ペンスなど、控えめに値下げされました。 • アラート: ウォッチドッグがネットワークの出力が正しくないと判断した場合、 これにより、アラートが公にトリガーされ、メカニズムが第 2 層ネットワークにエスカレートされます。 その場合、考えられる結果は 2 つあります。 – 正しいアラート: 第 2 層ネットワークが、図 16: 集中的な警告報酬による賄賂のコストの増大。賄賂 敵は、警告を発することで得られる報酬以上の報酬を各ノードに賄賂として贈らなければなりません。 (赤いバーで表示)。アラート報酬が共有される場合、この報酬は相対的に高くなります。 小さい。集中アラート報酬により、単一ノードが獲得できる報酬が増加します。 (赤い長いバー) を取得します。したがって、実行可能な賄賂に対する敵対者による支払総額は、 (灰色の領域) は、アラート報酬が共有よりも集中しているため、はるかに大きくなります。 第 1 層ネットワークが間違っていたため、警告を発したウォッチドッグ ノードが報酬を受け取ります すべての削減された預金で構成されるため、$dn/2 を超えます。 – 障害アラート: 第 2 層と第 1 層の oracle が同意した場合、エスカレーションは次のようになります。 故障とみなされ、警告ノードは $dw デポジットを失います。 レポートを楽観的に受け入れた場合、ウォッチドッグ アラートは発生しません。 依存契約の実行における変更。待つことを目的とした契約の場合 第二層委員会による仲裁の可能性、監視機関の警報は遅れるが、 契約の実行を凍結しないでください。契約書で指定することも可能です 判定期間中のフェイルオーバー DON。 9.4.2 二次ステーキングの影響 厳密なノード優先順位と組み合わせて、すべてのノードがウォッチドッグとして機能する機能 集中的な報酬を確保し、二次関数を達成するメカニズムを有効にします staking セクション9.3.3で説明されている各種の賄賂攻撃者への影響。これを思い出してください これは、特に私たちの設定において、それぞれがデポジットを持つ n 個のノードを持つネットワークの場合を意味します。 $d、成功した賄賂 (上記の種類のいずれか) は、 $dn2/2。 正確に言うと、賄賂は少なくとも (n+1)/2 ノードを破壊する必要があります。 n 個のノードの大部分が破損します (奇数 n の場合、仮定により)。したがって、ウォッチドッグは次のことを行います。 $d(n + 1)/2 の報酬を獲得します。したがって、賄賂はこの金額をすべての者に支払わなければなりません。node to ensure that none acts as a watchdog. We are working to show formally that if 賄賂の予算は最大 $d(n2 + n)/2 であり、サブゲームは完全な均衡になります。 賄賂者とoraclesの間のゲーム、言い換えれば、均衡 ゲームのプレイ中のどの時点でも、賄賂を受け取る側は賄賂を発行しません。 それぞれの oracle は、その真の値を正直に報告します。 上で、賄賂を成功させるためにどのようにして贈賄が要求される可能性があるかを説明しました。 ノードのデポジットの合計よりも大幅に大きい予算。これを説明すると 直感的な結果として、図 16 は集中アラート報酬の影響をグラフで示しています。 そこに見られるように、監視機関の警告に対する報酬、つまり賄賂の預金があった場合、 false を報告するノード) - すべての潜在的なアラートに分割され、合計量は 個々のアラート ノードは比較的小さいと予想されます。 $d。 賄賂は、d ドルを超える支払いがありそうもないことを知っていて、次のような手段を講じることができます。 n ノードのそれぞれに、 $d + ϵ。 直観に反しますが、図 16 は、報酬を広範囲に分配するシステムを示しています。 アラートを通知するノード間では、報酬を集中させるノードよりもはるかに弱いです。 the hands of a single watchdog. パラメータの例: 各ノードが n = 100 個ある (第 1 層) ネットワークを考えてみましょう。 depositing \(d = \)20K.このネットワークには合計 200 万ドルが入金されることになりますが、 予算\(100M = \)dn2/2の賄賂から保護されます。数を増やす もちろん、oracles は $d を増やすより効果的であり、劇的な効果が得られる可能性があります。 n = 300 ノードと \(d = \)20K のデポジットを持つネットワークは、 briber with budget up to $900M. staking システムは多くの場合、次の smart contract を保護できることに注意してください。 提供されている贈収賄防止レベルよりも価値のあるもの。 This is because an adversary これらの契約を攻撃しても、多くの場合、最大限の価値を引き出すことはできません。たとえば、 Chainlink を利用した契約で 10 億ドルの価値を確保するには、 そのような敵は利益を引き出すことができるため、1億ドルの資金を賄賂に渡す of only 10% of the value of the contract. 注: ネットワークの価値は二次関数的に増加する可能性があるという考えは、次のように表現されます。 よく知られているメトカーフの法則 [167, 235] では、ネットワークの価値は次のように述べられています。 接続されたエンティティの数は二次関数的に増加します。 Metcalfe’s Law, however, これは、潜在的なペアワイズ ネットワーク接続の数の増加から生じます。これは、インセンティブにおける 2 次 staking の基礎となる影響とは異なる現象です。 仕組み。 9.4.3 Realization of Second Tier 2 つの運用上の特徴により、高信頼性の 2 層目の実現が容易になります。 (1) oracle ネットワークでは第 2 層の裁定はまれなイベントであるはずなので、 第 1 層の通常の運用よりも大幅にコストがかかること、および (2)楽観的に受け入れられた報告書、または仲裁を待って実行できる契約書など 2 番目の層はリアルタイムで実行する必要はありません。 これらの機能により、さまざまな結果が得られます。 特定の DON の要件を満たすための 2 番目の層の構成オプション。 アプローチの例として、第 2 層委員会は、委員会によって選択されたノードで構成できます。 Chainlink 内で最も長くサービスを提供し、最も信頼性の高いノードからの DON (つまり、第 1 層) ネットワーク。オペレータは、相当な運用経験に加えて、 このようなノードの多くは、FFO に、欲望を動機付ける暗黙のインセンティブをかなり持っています。 Chainlink ネットワークの信頼性を高く保つため。彼らはまた、公に 信頼性の透明性を提供する利用可能なパフォーマンス履歴。注目に値するのは、第 2 層ノードは第 1 層ネットワークの参加者である必要はなく、 複数の第 1 層ネットワークにわたる障害を判断する場合があります。 特定の DON 内のノードは、そのような n ' 個のセットを事前に指定し、公にコミットできます。 DON の第 2 層委員会を構成するノード。さらに、DON ノードは、第 2 層の投票数を決定するパラメーター k' ≤n' を公開します。 第 1 層ノードにペナルティを与えるために必要です。特定のレポートに対してアラートが生成されると、 第 2 層のメンバーは、それぞれが提供する値の正しさに投票します。 第 1 層ノードの。 k' 個の否定票を受け取った第 1 層ノードはその権利を失います。 ウォッチドッグノードにデポジットします。 判決が下されることは稀であり、執行時間が延長される可能性があるため 前述したように、第 1 層とは対照的に、第 2 層のノードは次のことができます。 1. 裁判を行うことで高額の報酬を得る。 2. 最初の企業が使用する多様なセットを超えた追加のデータ ソースを利用します。 3. 手動および/または専門家の検査と介入に頼って、たとえば、特定および ソースデータのエラーを調整し、中継している誠実なノードを区別します。 欠陥のあるデータと誤動作するノード。 二次ノードの選択と判定を管理するポリシーについて説明したアプローチは、大きな枠組みの中の 1 点にすぎないことを強調します。 第 2 層の実現可能な設計空間。当社のインセンティブメカニズムが提供するもの 第 2 層の実現方法に関する完全な柔軟性。したがって、個々のDONは 特定の要件を満たす第 2 層のルールを構成および設定する 参加ノードとユーザーの期待。 判定ツールとしての DECO と Town Crier: ２層目では必須ですね 私たちのメカニズムでは、敵対的な第 1 層ノードを区別できるようになります。 意図的に誤ったレポートと、意図せずに正直な第 1 層ノードを作成する 送信元で不正なデータを中継します。そうして初めて第 2 層が実装できるようになります 私たちのメカニズムの目標である不正行為を阻止するためにスラッシュを行うことです。 DECOとタウンクライヤー は、第 2 層ノードがこの重要な区別を行えるようにする強力なツールです。 確実に。場合によっては、第 2 層ノードは使用されるデータ ソースを直接クエリできる場合があります。 第 1 層ノードによって実行するか、ADO セクション 7.1 を使用して、レポートが正しくないかどうかを確認します。 データ ソースの欠陥が原因です。ただし、他の場合には、第 2 層ノードに不足している可能性があります。 第 1 層ノードのデータ ソースへの直接アクセス。このような場合、正しい判決が下されると、 実行不可能であるか、主観的な判断に頼る必要があるように見えます。前 oracle 紛争システムは、このような問題に対処するために、非効率でエスカレートする投票ラウンドに依存してきました。 課題。 ただし、DECO または Town Crier を使用すると、第 1 層ノードが正しい動作を証明できます。 第 2 層ノードに。 (2 つのシステムの詳細については、セクション 3.6.2 を参照してください。)具体的には、 第 2 層ノードは、第 1 層ノードが欠陥のあるレポート値 ˜r を出力したと識別し、 第 1 層ノードは DECO または Town Crier を使用して改ざん防止の証拠を生成できます。 第 2 層ノードは、(TLS 対応の) ソースから正しく中継されているかどうかを確認します。 DON によって権威あるものとして認識されています。重要なのは、第 1 層ノードがこれを実行できることです。 データ ソースへの直接アクセスを必要とする第 2 層ノードは必要ありません。17 その結果、 Chainlink では、任意のデータ ソースに対して正しい判断が可能です。 9.4.4 保険の虚偽報告 当社のstakingメカニズムによって達成される強力な贈収賄防止は、根本的に依存しています 警告者に与えられる資金の削減について。金銭的な報酬がなければ、警告者は 賄賂を拒否する直接的な動機はありません。しかし、その結果、削減された資金は 誤った報告によって被害を受けたユーザー（金銭を失ったユーザーなど）を補償するために利用可能 誤った価格データが smart contract に中継された場合。 仮定として、レポートが承認された場合、間違ったレポートは問題を引き起こしません。 潜在的な裁定、つまり第 2 層による措置の後にのみ契約を締結します。説明どおり ただし、可能な限り最高のパフォーマンスを達成するために、契約では代わりに上記に依存する場合があります。 正しい報告を強制するメカニズムについて楽観的に考えており、これは受け入れられることを意味します。 潜在的な第二段階の裁定の前に報告する。 確かに、そのような楽観的な行動は、 予算が上限を超えない合理的な敵を想定したモデルでは安全です。 staking メカニズムの影響。 ユーザーは、機構の故障というありえない事態を懸念しており、 たとえば、圧倒的な資金力を持つ敵対者は、保険の虚偽報告という形で経済的安全の追加層を採用したいと考えるかもしれません。私たちは知っています 複数の保険会社がすでにこの種のスマートコントラクトに裏付けられた保険を提供するつもりです Chainlink で保護されたプロトコルは、DAO (例: [7]) などの革新的なメカニズムを通じて、近い将来実現されます。 Chainlink のパフォーマンス履歴の存在 ノードおよびそのステーク額などのノードに関するその他のデータは、保険数理によるリスク評価の非常に強力な基礎を提供し、保険契約の価格設定を可能にします。 保険契約者にとっては安価でありながら、保険会社にとっては持続可能な方法で。 17Town Crier を使用すると、第 1 層ノードがローカルで証明書を生成することも可能になります 出力されたレポートの正確性を検証し、これらの証明書を第 2 層ノードに提供します。 必要に応じてベース。誤報保険の基本的な形式は、信頼できる方法で実装できます。 smart contracts を使用した効率的な方法。簡単な例として、パラメトリック保険 当社のインセンティブメカニズムが有効であれば、契約SCinsは保険契約者に自動的に補償することができます。 2 番目の層は、1 番目の層で生成されたレポートのエラーを特定します。 保険契約を希望するユーザ U、例えばターゲットの作成者 契約 SC は、分散型保険会社に保険金額のリクエストを送信できます 契約は百万ドル。 U を承認すると、保険会社は継続的な (例: 毎月) を設定できます。 SCins で $P のプレミアム。 U が保険料を支払っている間、彼女の保険は有効のままです。 SC でレポートの失敗が発生した場合、結果としてペア (r1、r2) が出力されます。 SC の競合するレポート。ここで、r1 はメカニズムの最初の層によって署名されており、 r2 (対応する修正レポート) は、第 2 層によって署名されます。 U が提供する場合 このような有効なペア (r1、r2) を SCins に指定すると、契約により自動的に $M が彼女に支払われます。 彼女の保険料の支払いは最新のものです。 9.5 シングルラウンドのバリエーション 前のサブセクションで説明したプロトコルでは、第 2 層委員会は、ウォッチドッグが警告を発したかどうかを判断するために n ラウンド待機する必要があります。 これ この要件は、楽観的なケース、つまり最初の層が機能している場合でも当てはまります。 正しく。レポートを楽観的に受け入れたくないユーザー、つまり潜在的な可能性が生じる前に 判決が下されると、そのアプローチに伴う遅延は実行不可能になります。 このため、私たちは 1 つだけを必要とする代替プロトコルも検討しています。 丸い。このアプローチでは、すべての oracle ノードが、次のいずれかを示す秘密ビットを送信します。 彼らは警告を発したいと考えています。次に、第 2 層委員会がこれらの値をチェックします。 優先順位。大まかなスケッチを提供するには、このようなスキームには次のものが含まれる可能性があります。 手順: 1. ウォッチドッグ ビットの送信: 各ノードは 1 ビットのウォッチドッグ値を秘密共有します。 生成されるレポートごとに、第 2 層のノード間で wi ∈{アラートなし、アラート} が発生します。 2. 匿名ヒント: 任意の oracle ノードは、ウォッチドッグ ビットが送信されるのと同じラウンドで、匿名のヒント α を第 2 層委員会に送信できます。このヒントα 現在のレポートに対してアラートが発生したことを示すメッセージです。 3. ウォッチドッグ ビット チェック: 第 2 層委員会は oracle ノードのウォッチドッグを明らかにします ビットを優先順位順に並べます。 ノードは、アラートを出さないときはアラート ウォッチドッグ ビットを送信してはならないことに注意してください。そうしないと、トラフィック分析によってすべてのノードのビットが明らかになります。プロトコルはアラートなしを明らかにします 最も優先順位の高いアラート ウォッチドッグよりも高い優先順位を持つノードのウォッチドッグ ビット。 明らかになったものは、n ラウンド プロトコルのものと同じであることに注目してください。報酬もそのスキーム、つまり最初に特定されたウォッチドッグと同様に分配されます。 は、誤ったレポートを提出したノードの削減されたデポジットを受け取ります。匿名のヒントを使用すると、警告が発せられていない場合でも第 2 層委員会は非対話型のままとなり、コミュニケーションの複雑さが軽減されます。 一般的なケースでは。警告を発する監視機関には、匿名のヒントを提出する経済的インセンティブがあることに注意してください。ヒントが提出されない場合、報酬は支払われません。 ノード。 匿名の情報αの送信者Oiが特定できないようにするため。 ネットワーク データに基づいて敵対者に匿名の情報を送信することができます。 たとえば、Tor 経由、またはより現実的には、クラウド サービス プロバイダー経由でプロキシされたチャネルです。へ チップが O から発信されたものであると認証すると、Oi はリング署名を使用して α に署名できます [39、192]。 あるいは、悪意のある oracle ノードによる第 2 層委員会に対する原因不明のサービス拒否攻撃を防ぐために、α を匿名の資格情報にすることもできます。 取り消し可能な匿名性 [73]。 このプロトコルは、実際には実現可能ですが、やや重いエンジニアリングを必要とします。 要件（これを削減する方法を検討中です）。たとえば、第 1 層ノードは次のようになります。 第 2 層ノードと直接通信する必要があるため、ディレクトリのメンテナンスが必要になります。匿名チャネルとリング署名の必要性によりエンジニアリングが増加します スキームの複雑さ。最後に、特別な信頼要件について簡単に説明します。 以下のメモにあります。したがって、私たちは、依然として達成できるより単純なスキームも模索しています。 超線形 staking の影響はありますが、おそらく 2 次よりは小さいでしょう。たとえば、賄賂が漸近的に少なくとも $n log n のリソースを必要とする場合です。以下のスキームの一部 考慮事項には、ウォッチドッグとして機能するノードの厳密なサブセットのランダムな選択が含まれます。 この場合、将来的な贈収賄は特に強力な攻撃となります。 備考: この単一ラウンド staking メカニズムのセキュリティには、利用できないことが必要です oracle と第 2 層ノード間のチャネル - 投票 [82、138] などの耐強制性システムの標準要件であり、実際には合理的な要件です。 ただし、さらに、賄賂と協力しようとするノード Oi は、 特定の暗号化を行ったことを賄賂に示すような方法で秘密共有を行う 値。たとえば、Oi が賄賂がどのノードを制御しているかわからない場合、Oi は次のことができます。 価値ゼロの株式をすべての委員会メンバーに提出します。贈収賄者はその後、Oi の内容を確認できます。 確率的にコンプライアンスを達成します。シングルラウンドプロトコルでこの問題を回避するには、次のようにします。 Oi は、少なくとも 1 つの正直な第 2 層ノードの ID を知っている必要があります。 各第 2 層ノードがランダム化を追加する対話型プロトコルを使用 株式の要因となるため、贈収賄者ができる最善のことは、Oi による無作為の選択を強制することです。 ウォッチドッグビット。 9.6 暗黙的インセンティブ フレームワーク (IIF) FFO は、Chainlink ネットワーク内での正しい動作に対する暗黙的なインセンティブの一種です。それ 経済的安全を確保するのに役立つという点で、明示的な賭け金、つまり預金と同様に機能します。 ネットワーク。言い換えれば、FFO は（有効な）デポジットの一部として含まれる必要があります。 ネットワーク内のノードの $d。問題は、FFO やその他の形式の暗黙的インセンティブをどのように測定するかです。 Chainlink ネットワーク内ですか? 暗黙的インセンティブ フレームワーク (IIF) は、次のセットです。 この目的のために私たちが開発する予定の原理と技術。ブロックチェーンシステム さまざまな形で前例のない透明性とノードの信頼性の高い記録を提供します 彼らが生み出すパフォーマンスは、IIF がどのように機能するかについての私たちのビジョンへの出発点となります。 ここでは、IIF の主要な要素に関するアイデアを非常に簡単に説明します。 IIF 自体は、評価において重要であると当社が特定した一連の要素で構成されます。 暗黙のインセンティブと、分析アルゴリズムで使用できるように関連データを高保証形式で公開するメカニズム。さまざまなChainlinkユーザーが さまざまな方法で IIF を使用したい、たとえば、さまざまな要素にさまざまな重み付けを適用したい。 ユーザーが IIF を適用するのを支援する分析サービスがコミュニティで生まれることを期待しています。 個々のリスク評価の好みに応じて、私たちの目標は、リスク評価を促進することです。 高保証でタイムリーなサポート データへのアクセスを保証することで、そのようなサービスを提供します。 以下で説明します (セクション 9.6.4)。 9.6.1 将来の手数料の機会 ノードは、Chainlink エコシステムに参加して、このペーパーで説明したさまざまなサービスに対してネットワークが支払う料金の一部を受け取ります。 分散型アイデンティティ、公平な順序付け、 機密保持 DeFi。 Chainlink ネットワークの料金は、サーバーの実行、必要なデータ ライセンスの取得、保守などのノード オペレーターのコストをサポートします。 高い稼働時間を保証するグローバルスタッフ。 FFO は諸経費を除いたサービス料金を表します。 ノードが将来得られる可能性があること、またはノードが誤った動作を示した場合には失われる可能性があること。 FFO は、ネットワークのセキュリティを確保するのに役立つステークの形式です。 FFO の便利な機能は、オンチェーン データ (オフチェーンによって補完される) であるという事実です。 データ) ノードの履歴に関する信頼性の高い記録を確立し、FFO の計算を可能にします 透明性があり、経験に基づいた方法で。 FFO の単純な一次測定は、企業の平均純収益から導き出すことができます。 一定期間にわたるノードの推移 (つまり、総収益から営業経費を差し引いたもの)。 FFOかもしれない 次に、たとえば、将来の累積純収益の正味現在価値 [114] として計算されます。 言い換えれば、将来のすべての収益を時間割引した値です。 ただし、図 17 の例に示すように、ノードの収益は変動する可能性があります。 さらに重要なのは、ノードの収益が定常的な分布に従わない可能性があることです。 時間が経つにつれて。したがって、FFO を推定する際に調査する予定のその他の要因には次のものがあります。 • パフォーマンス履歴: オペレーターのパフォーマンス履歴 (レポートの正確性と適時性、稼動時間など) が目標を提供します。 ユーザーがその信頼性を評価するための試金石。 したがって、パフォーマンス履歴は、 ユーザーが oracle ノードを選択する際の重要な要素を提供します (または、出現により DON の、DON の選択）。好調なパフォーマンス履歴は、 継続的な高い収益と相関関係があります。18 18私たちが取り組む予定の重要な研究課題は、改ざんされたサービス量の検出です。図 17: 単一データ フィード (ETH-USD) で Chainlink ノードが獲得した収益 2021年3月の代表的な週。 • データ アクセス: oracles はオープン API からさまざまな形式のデータを取得できますが、 特定の形式のデータまたは特定の高品質のソースは、 サブスクリプションベースまたは契約上の合意を通じて。特定のものへの特権アクセス データ ソースは、安定した収益源を生み出す役割を果たすことができます。 • DON への参加: DONs の出現により、ノードのコミュニティが登場します。 特定のサービスを提供するために連携します。多くの DON には次のものが含まれると予想されます。 選択ベースでオペレーターを選択し、評判の高い DON への参加を確立します。 市場での特権的な地位を確保し、安定した収益源を確保します。 • クロスプラットフォームのアクティビティ: 一部のノードオペレーターは、他のコンテキスト (PoS validator や blockchain 以外のコンテキストのデータ プロバイダー。これらの他のシステムでのパフォーマンス (データが信頼できる形式で利用可能な場合) が評価に影響を与える可能性があります。 彼らの演奏履歴。同様に、Chainlink ネットワークでの誤った動作 ユーザーを遠ざけることにより、これらの他のシステムの収益を危険にさらす可能性があります (FFO など) プラットフォーム間で拡張できます。 9.6.2 投機的FFO ノード オペレーターは、収益を生み出すためだけではなく、Chainlink ネットワークに参加します。 業務を遂行するだけでなく、ジョブを実行するための新しい機会を活用するために自らを立ち上げ、配置することも必要です。つまり、ネットワーク内の oracle ノードによる支出も DeFi およびその他のスマート コントラクト アプリケーションの将来についての前向きな声明 ドメインだけでなく、oracle ネットワークの新興の非blockchain アプリケーションも同様です。現在、ノード オペレーターは既存の Chainlink ネットワークで利用可能な料金を得ると同時に、 これらは、問題がより簡単であることを除けば、インターネット サイト上の偽レビューとほぼ似ています。 oracle 設定は、商品 (レポートなど) が注文されたかどうかの決定的な記録があるためです。 たとえば、オンライン ショップで注文した物理的な商品とは対照的に、配送されます。別の言い方をすると、oracle 設定を変更すれば、顧客の真実性が証明できない場合でも、パフォーマンスを検証できます。評判、実績履歴、運用上の専門知識を構築し、 将来のネットワークで利用できる手数料を有利に稼ぐことができます（もちろん、条件付きですが）。 正直な行動について）。現在 Chainlink エコシステムで動作しているノードは、 Chainlink として追加料金を稼ぐ点で、新規参入者よりも有利な感覚を持っています。 サービスが利用可能になります。この利点は、新しい通信事業者だけでなく、定評のあるテクノロジー企業にも当てはまります。たとえば、T-Systems は従来の テクノロジープロバイダー (ドイツテレコムの子会社)、および大規模な集中型サービスである Kraken Exchange は、Chainlink エコシステムで初期の存在感を確立しました [28、143]。 oracle ノードによる将来の機会へのそのような参加は、それ自体とみなされます 一種の投機的な FFO として、Chainlink における一種の株式を構成します。 ネットワーク。 9.6.3 外部からの評判 IIF は、これまで説明したように、厳密に匿名化されたネットワーク内で動作できます。 つまり、関係する人々や現実世界のエンティティは開示されません。 ただし、ユーザーがプロバイダーを選択する際に潜在的に重要な要素の 1 つは外部要因です。 評判。外部の評判とは、偽名ではなく現実世界のアイデンティティに付随する信頼性の認識を意味します。風評リスクが伴う 現実世界のアイデンティティは、暗黙のインセンティブの一形態とみなすことができます。評判を見る IIFのレンズを通して、つまり暗号経済的な意味で、 FFO の推定値に組み込まれる可能性のあるクロスプラットフォームのアクティビティ。 FFO の推定の要素として外部の評判を使用することの利点とは対照的に 仮名リンクとは、外部の評判がパフォーマンスにリンクするだけでなく、 オペレーターの既存の活動だけでなく、将来の活動にも適用されます。例えば評判が悪い場合 個人に執着すると、その人の将来の事業を汚す可能性があります。別の言い方をすると、外部の評判は匿名よりも広範囲の FFO を捉えることができます。 個人または確立された不正行為の影響としての業績記録 会社から逃れるのは、偽名運営に関連する会社よりも困難です。 Chainlink は、分散型 ID テクノロジー (セクション 4.3) と互換性があります。 IIF での外部レピュテーションの使用のサポートを提供できます。このような技術 検証することができ、それによってオペレータが主張する現実世界の真実性を保証するのに役立ちます アイデンティティ.19 9.6.4 IIF アナリティクスを開く すでに述べたように、IIF は信頼できるオープンソース データとツールを提供することを目的としています。 暗黙的なインセンティブ分析。 目標は、コミュニティ内でプロバイダーを有効にすることです 組織のさまざまな部分のリスク評価ニーズに合わせた分析を開発するため Chainlink ユーザー ベース。 19分散型アイデンティティ認証情報では、必要に応じて、検証済みの仮名を装飾することもできます。 補足情報。たとえば、ノード オペレータは原則としてそのような認証情報を使用して、 フォーチュン 500 企業であることを証明しますが、どの企業であるかは明らかにしません。ノードの収益とパフォーマンスに関する大量の履歴データ 信頼性の高い不変形式でチェーン上に存在します。ただし、私たちの目標は、 オフラインでのみ表示される行動に関するデータを含む、可能な限り最も包括的なデータ チェーン (オフチェーン レポート (OCR) や DON アクティビティなど)。このようなデータは、潜在的に ボリュームがあること。それを保管し、その完全性を確保するための最良の方法、つまり、次のようなことから保護します。 改ざんは、DON の助けを借りて、ここで説明した手法を使用して行われると考えられます。 セクション 3.3 で説明します。 staking など、一部のインセンティブは直接的な測定形式に適しています。 デポジットと基本的な FFO。投機的な FFO や評判など、他のものはより困難です。 客観的な方法で測定しますが、次のような形式のデータをサポートすることが重要であると考えています。 Chainlink エコシステムの歴史的成長、ソーシャルメディアの評判指標など、 は、これらの定量化が難しい要素についても IIF 分析モデルをサポートできます。 専用の DON は、特に監視、検証、および監視のために発生すると想像できます。 ノードのオフチェーンパフォーマンス記録に関連する記録データおよびその他のデータ IIF で使用される、検証された ID 情報など。これらの DON は、Chainlink コミュニティにサービスを提供する分析プロバイダーに均一で信頼性の高い IIF データを提供できます。 また、分析プロバイダーの主張を裏付ける黄金の記録も提供します。 コミュニティによって独立して検証可能。 9.7 すべてをまとめると: ノード オペレーターのインセンティブ ノードオペレーターに対する明示的および暗黙的なインセンティブに関する上記の議論を総合すると、 ノードオペレーターが参加し、そこから利益を得る方法の全体的なビューを提供します。 Chainlink ネットワーク。 概念的なガイドとして、危機に瀕している総資産を特定の Chainlink で表すことができます。 ノード オペレーター $S の大まかな様式化された形式は次のとおりです。 \(S ≈\)D + \(F + \)FS + $R、 ここで: • $D は、すべてのネットワークにわたって明示的に預けられたすべてのステークの合計です。 オペレーターが参加します。 • $F は、すべてのネットワークにわたるすべての FFO を合計した正味現在価値です。 オペレーターが参加します。 • $FS は、オペレーターの投機的 FFO の正味現在価値です。そして • $R は、Chainlink エコシステム外のオペレーターの評判資産です。 これは、oracle ノードで確認された不正行為によって危険にさらされる可能性があります。 この大まかな等価性は主に概念的なものではありますが、Chainlink ノードによる高信頼性パフォーマンスを促進する経済的要因が多数存在することを示しています。 $D 以外のこれらの要素はすべて、今日の Chainlink ネットワークに存在します。9.8 経済安全保障の好循環 超線形 staking の影響と料金支払いの表現の組み合わせ IIF における将来の手数料機会 (FFO) は、いわゆる好循環をもたらす可能性があるためです。 oracle ネットワークにおける経済的安全性。これは一種の経済と見ることができます 規模の。特定のネットワークによって保護される総量が増加するにつれて、 一定額の経済的安全を追加するために必要な追加の賭け金は減少するにつれて減少します ユーザーあたりの平均コスト。したがって、ユーザーが参加する料金の面では安くなります。 既存のネットワークを使用して同じネットワーク経済性の向上を達成するよりも 新しいネットワークを作成することでセキュリティを強化します。重要なのは、新しいユーザーが追加されるたびに、 そのネットワークの以前のすべてのユーザーのサービスのコスト。 特定の料金体系（賭け金に対する特定の利回りなど）を考慮すると、 ネットワークが獲得する合計料金が増加すると、追加料金の流れが促進されます。 ネットワークに参加して、より高いレートでネットワークを保護します。具体的には、賭け金の総額が システム内で個々のノードが保持できる上限が設定されている場合、新しい料金の支払いが行われるとき システムに入力すると、FFO が増加し、ノード数 n が増加します。おかげで 私たちのインセンティブ システム設計の超線形な影響、経済的安全性 システムは n よりも速く立ち上がります (たとえば、セクション 9.4 で説明するメカニズムでは n2 のように)。 その結果、経済的安全保障の平均コスト、つまり貢献する出資額は 経済安全保障の 1 ドルは減少するでしょう。したがって、ネットワークはユーザーに料金を請求することができます 手数料が安くなる。 oracle サービスの需要は柔軟であると仮定します (たとえば、概要については [31] を参照してください) 説明）、需要が増加し、追加料金と FFO が発生します。 この点を次の例で説明します。 例 5. インセンティブによる oracle ネットワークの経済的安全性 スキームは \(dn2 for stake \)dn、1 ドルの賭け金によって経済的安全が提供されます は n なので、経済安全保障の 1 ドルあたりの平均コスト、つまり賭け金の額となります。 1 ドルの経済安全保障への貢献は 1/n です。 経済的インセンティブが完全に FFO で構成され、上限が設定されているネットワークを考えてみましょう。 ノードあたり\(d ≤\)10K。ネットワークに n = 3 個のノードがあると仮定します。そうすると平均費用は 経済安全保障は 1 ドルあたり約 0.33 ドルです。 ネットワークの合計 FFO が \(30K (e.g., to \)31K を超えると仮定します。与えられた ノードごとの FFO の上限を設定すると、ネットワークは (少なくとも) n = 4 まで拡大します。ここで、平均コストは次のようになります。 経済安全保障は 1 ドルあたり約 0.25 ドルに低下します。 oracle ネットワークにおける経済安全保障の完全な好循環を図 18 に概略的に示します。 我々は、経済安全保障の好循環は次のような効果から生まれることを強調する。 料金をプールするユーザーの割合。 より大きな組織に有利に働くのは、彼らの集合的な FFO です。 ネットワークの規模が大きくなり、集団的なセキュリティが強化されます。また、好循環にも注目します。 経済的安全の確保は、DON が経済的な持続可能性を達成するのに有利に働きます。一度 ユーザーのニーズに対応する DON が作成され、その時点以上に成長する必要があります。 手数料による収益が oracle ノードの運用コストを超えています。

Revenue earned by Chainlink nodes on a single ETH-USD data feed showing correlation with price volatility

Diagram showing how concentrated alerting rewards amplify the cost for a briber attempting to corrupt the oracle network

Schematic of Chainlink staking scheme with alerting showing watchdog escalation and penalty mechanisms

Schematic of the virtuous cycle of Chainlink staking showing how user fees drive security and value capture

図 18: Chainlink staking の好循環の概略図。利用料の値上げ oracle ネットワーク 1⃝への支払いはネットワークを成長させ、経済成長につながります セキュリティ 2⃝。この超直線的な成長により、Chainlink ネットワークのスケールメリットが実現します 3⃝。具体的には、経済安全保障の平均コストの削減を意味します。 手数料の支払いまたはその他の出資源から生じる1ドルあたりの経済的安全性 が増加します。コストの削減がユーザーに還元され、oracle の需要が増加します サービス4⃝。 9.9 ネットワークの成長を促進する追加の要因 Chainlink エコシステムが拡大し続けるにつれて、その魅力はさらに高まると考えています。 ユーザーにとっての重要性が高まり、blockchain 経済のインフラとしての重要性が加速します。 oracle ネットワークによって提供される値は超線形であり、より速く成長することを意味しますネットワーク自体のサイズよりも。 この価値の増加は、次の両方に由来します。 スケールメリット - サービス量の増加に伴うユーザーあたりのコスト効率の向上 - そして ネットワーク効果 - ユーザーが DON をより広く採用するにつれて、ネットワーク ユーティリティが増加します。 既存の smart contract には引き続き、より多くの価値が確保され、まったく新しいものとなります。 smart contract アプリケーションは、より分散化されたサービスによって可能になり、合計 DON の使用および支払われる料金の総額は増加するはずです。 手数料プールの増加 さらに分散化されたサービスを作成するための手段とインセンティブに変換されます。 好循環が生まれます。 この好循環により、卵が先か鶏が先かという重大な問題が解決されます。 ハイブリッド smart contract エコシステムの問題: 革新的な smart contract 機能 多くの場合、まだ存在しない分散型サービスが必要になります (例: 新しい DeFi 市場が頻繁に存在します) 新しいデータフィードが必要ですが、その実現には十分な経済的需要が必要です。 既存の DON に対するさまざまな smart contract による料金のプールは、 拡大するユーザーベースからの追加の分散型サービスが誕生し、 DONs によるものと、新しく多様なハイブリッド smart contracts の継続的な有効化です。 要約すると、ネットワーク セキュリティの成長は高潔な取り組みによって促進されると考えています。 Chainlink staking メカニズムのサイクルは、より大きな成長パターンを例示しています。 Chainlink ネットワークは、分散型のオンチェーン経済を実現するのに役立ちます サービス。

Phần kết luận

Trong bài viết này, chúng tôi đã đặt ra tầm nhìn về sự phát triển của Chainlink. Chủ đề chính trong tầm nhìn này là khả năng của các mạng oracle trong việc cung cấp phạm vi dịch vụ rộng hơn nhiều cho smart contracts hơn là chỉ phân phối dữ liệu. Sử dụng DON làm nền tảng cho các dịch vụ phi tập trung trong tương lai, Chainlink sẽ nhằm mục đích cung cấp chức năng oracle được nâng cao hiệu quả, bảo mật. Mạng oracle của nó sẽ cung cấp khả năng giảm thiểu tin cậy mạnh mẽ thông qua sự kết hợp của các cơ chế kinh tế mật mã nguyên tắc như staking và các đường ray bảo vệ được hình thành cẩn thận và thực thi cấp độ dịch vụ dựa trên các chuỗi chính. DONs cũng sẽ giúp các hệ thống lớp 2 thực thi các chính sách đặt hàng công bằng, linh hoạt đối với các giao dịch cũng như giảm chi phí gas cho các giao dịch được định tuyến theo mempool. Gộp lại với nhau, tất cả những khả năng này đều hướng tới sự an toàn và đa chức năng kết hợp thông minh hợp đồng. Tính linh hoạt của DON sẽ nâng cao các dịch vụ Chainlink hiện có và làm phát sinh nhiều tính năng và ứng dụng smart contract bổ sung. Trong số này là liền mạch kết nối với nhiều hệ thống ngoài chuỗi, tạo danh tính phi tập trung từ dữ liệu hiện có, các kênh ưu tiên để giúp đảm bảo cung cấp kịp thời các cơ sở hạ tầng quan trọng giao dịch và các công cụ DeFi bảo mật bí mật. Tầm nhìn chúng tôi đặt ra ở đây đầy tham vọng. Trong ngắn hạn, chúng tôi tìm cách trao quyền hợp đồng kết hợp để hoàn thành các mục tiêu ngoài tầm với của smart contract giây hôm nay, trong khi về lâu dài, chúng tôi mong muốn hiện thực hóa một lớp kim loại phi tập trung. Thật hạnh phúc khi chúng ta có thể vẽ về các công cụ và ý tưởng mới—từ thuật toán đồng thuận đến bằng chứng không có kiến thức hệ thống—mà cộng đồng đang phát triển là thành quả của nghiên cứu đang phát triển nhanh chóng.

Tương tự, chúng tôi hy vọng sẽ ưu tiên thực hiện các ý tưởng trong bài viết này để đáp ứng đáp ứng nhu cầu của cộng đồng người dùng Chainlink. Chúng tôi mong chờ giai đoạn tiếp theo trong nỗ lực của chúng tôi nhằm trao quyền cho smart contract thông qua kết nối toàn cầu và thiết lập công nghệ phi tập trung như là xương sống của thế hệ tài chính tiếp theo của thế giới và các hệ thống pháp luật. Lời cảm ơn Cảm ơn Julian Alterini và Shawn Lee đã đưa ra các số liệu trong bài viết này.

結論

この文書では、Chainlink の進化のビジョンを示しました。メインテーマ このビジョンでは、oracle ネットワークがより広範囲のサービスを提供できるようにすることを目指しています。 単なるデータ配信よりも smart contract 秒。 DON を将来の分散型サービスの基盤として使用し、Chainlink は、パフォーマンスが高く機密性が強化された oracle 機能を提供することを目指します。その oracle ネットワークは強力な信頼の最小化を提供します staking や 慎重に考えられたガードレールと、依存するメインチェーンに対するサービスレベルの強制。 DONs は、レイヤー 2 システムがトランザクションに対して柔軟で公平な順序付けポリシーを適用し、メモリプール経由のトランザクションのガスコストを削減するのにも役立ちます。まとめると、 これらの機能はすべて、安全で機能豊富なハイブリッド スマートの方向に推進します。 契約。 DONs の柔軟性により、既存の Chainlink サービスが強化され、 多くの追加の smart contract 機能とアプリケーション。その中にはシームレスなものもあります さまざまなオフチェーン システムへの接続、分散型アイデンティティの作成 既存のデータ、インフラストラクチャに不可欠なデータをタイムリーに配信するための優先チャネル トランザクション、および機密保持 DeFi 文書。 私たちがここで定めたビジョンは野心的なものです。短期的には、私たちは力を与えることを目指しています ハイブリッド契約は、今日の smart contract 人の手の届かない目標を達成するために契約されますが、 長期的には、分散型メタレイヤーの実現を目指しています。幸せに絵を描くことができます コンセンサスアルゴリズムからゼロ知識証明に至るまで、新しいツールやアイデアについて コミュニティが急速に進化する研究の成果として開発しているシステム。

同様に、この文書のアイデアの実装を優先する予定です。 Chainlink のユーザー コミュニティのニーズに応えます。次のステージを楽しみにしています ユニバーサル接続を通じて smart contract を強化し、 世界の次世代金融のバックボーンとしての分散型テクノロジー そして法制度。 謝辞 この文書の図をレンダリングしてくれた Julian Alterini と Shawn Lee に感謝します。