체인링크: 분산형 오라클 네트워크
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 네트워크의 역할이 점차 확대되고 있으며, 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 오프체인 계산 smart contracts. 우리 계획의 기초는 분산형 Oracle 네트워크라고 부르는 것입니다. 줄여서 DONs입니다. DON은 Chainlink 위원회에서 유지 관리하는 네트워크입니다. 노드. 선택한 oracle 기능을 무제한으로 지원합니다. 위원회에 의한 배치. 따라서 DON은 강력한 추상화 계층 역할을 합니다. 광범위한 오프체인 리소스에 대한 smart contracts에 대한 인터페이스를 제공하고 DON 자체 내 효율적이면서도 분산된 오프체인 컴퓨팅 리소스입니다. DONs를 발판으로 Chainlink은 7개 분야의 발전에 집중할 계획입니다. 주요 분야: • 하이브리드 smart contracts: 온체인을 안전하게 구성하여 기존 smart contract 기능을 강화하기 위한 강력하고 일반적인 프레임워크 제공 그리고 오프체인 컴퓨팅 리소스를 우리가 하이브리드 smart contract라고 부르는 것으로 만들었습니다. • 복잡성 추상화: 개발자와 사용자에게 간단한 설명을 제공합니다. 기능을 사용하면 복잡한 기본 기능에 익숙할 필요가 없습니다. 프로토콜 및 시스템 경계. • 확장: oracle 서비스가 지연 시간 및 처리량을 달성하도록 보장 고성능 분산 시스템이 요구하는 것입니다. • 기밀성: blockchains'를 결합한 차세대 시스템 구현 민감한 정보에 대한 강력한 새 기밀 보호 기능을 갖춘 타고난 투명성 데이터. • 거래에 대한 주문 공정성: 다양한 방식으로 거래 순서 지원 최종 사용자에게 공정하고 선행 공격 및 기타 공격을 방지합니다. 봇과 착취적인 광부. • 신뢰 최소화: 매우 신뢰할 수 있는 지원 계층 생성 smart contracts 및 기타 oracle 종속 시스템은 분산화, 높은 보안 수준의 강력한 고정 blockchains, 암호화를 통해 기술 및 암호화폐 경제 보장. • 인센티브 기반(암호경제적) 보안: DONs의 노드가 자원이 풍부한 적들 앞에서도 안정적이고 올바르게 행동할 수 있는 강력한 경제적 인센티브를 갖도록 하는 메커니즘을 엄격하게 설계하고 강력하게 배포합니다. 우리는 Chainlink 커뮤니티의 예비적이고 지속적인 혁신을 제시합니다. 각 영역에서 확장되고 점점 더 커지는 그림을 제공합니다. Chainlink 네트워크에 강력한 기능이 계획되어 있습니다.
Giới thiệu
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.
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ị.
• 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.
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.
소개
블록체인 oracle은 오늘날 한 가지 목표를 가진 분산형 서비스로 간주되는 경우가 많습니다. 오프체인 리소스의 데이터를 blockchains로 전달합니다. 짧은 걸음이지만, 데이터 전달부터 컴퓨팅, 저장, 양방향 전송까지. 이러한 관찰은 oracles의 기능에 대한 훨씬 더 광범위한 개념을 정당화합니다. 너무도 smart contracts의 증가하는 서비스 요구 사항을 수행하고 점점 더 다각화됩니다. oracle 네트워크에 의존하는 기술. 간단히 말해서, oracle는 다음을 수행할 수 있고 필요합니다. 온체인 시스템과 오프체인 시스템 간의 범용, 양방향, 컴퓨팅 지원 인터페이스입니다. blockchain 생태계에서 오라클의 역할은 smart contract의 성능, 기능 및 상호 운용성을 다양한 산업에 새로운 신뢰 모델과 투명성을 제공합니다. 이러한 변화는 하이브리드 smart contract의 사용 확대를 통해 이루어질 것입니다. blockchains의 특별한 속성은 다음과 같은 오프체인 시스템의 고유한 기능을 갖추고 있습니다. oracle 네트워크를 구축하여 온체인 시스템보다 훨씬 더 큰 도달 범위와 성능을 달성합니다. 고립되어 있습니다. 이 백서에서 우리는 원래 Chainlink 백서 [98]의 초기 개념을 뛰어넘는 Chainlink의 진화인 Chainlink 2.0에 대한 비전을 명확히 설명합니다. 우리는 oracle 네트워크의 역할이 점점 더 확장될 것으로 예상합니다. 하이브리드를 위한 빠르고 안정적이며 기밀성을 유지하는 범용 연결 및 계산을 제공하여 기존 및 새로운 blockchain을 보완하고 향상합니다. smart contracts. 우리는 oracle 네트워크가 유틸리티로 발전할 것이라고 믿습니다. 높은 무결성의 blockchain급 데이터를 blockchain 이상의 시스템으로 내보내는 데 사용됩니다. 생태계. 오늘날 다양한 개체 집합이 운영하는 Chainlink 노드는 oracle 네트워크에 모여 보고서라고 알려진 데이터를 smart contract에 전달합니다. 우리는 그러한 것을 볼 수 있습니다 oracle 노드는 고전적 합의 blockchain [72]과 유사한 위원회로서, 그러나 독립된 기능을 제공하기보다는 기존 blockchain을 지원하는 것이 목표입니다. 검증 가능한 무작위 함수(VRF) 및 오프체인 보고 (OCR), Chainlink은(는) smart contract에 필요한 계산 리소스를 제공하기 위한 범용 프레임워크 및 인프라로 이미 발전하고 있습니다. 고급 기능. Chainlink 2.0에 대한 우리 계획의 기초는 우리가 분산형 Oracle이라고 부르는 것입니다. 네트워크, 줄여서 DON입니다. "oracle 네트워크"라는 용어를 도입한 이후 원본 Chainlink 백서 [98], oracles는 더욱 풍부한 기능과 적용 범위가 넓습니다. 본 논문에서는 다음과 같은 용어에 대한 새로운 정의를 제공합니다. Chainlink 생태계에 대한 미래 비전을 소개합니다. 이 보기에서 DON은 네트워크입니다. Chainlink 노드로 구성된 위원회에서 유지관리합니다. 합의 프로토콜에 뿌리를 두고 있으며, 배포를 위해 선택한 oracle 기능을 무제한으로 지원합니다. 위원회. 따라서 DON는 blockchain 추상화 계층 역할을 하여 인터페이스를 제공합니다. smart contracts 및 기타 시스템 모두에 대한 오프체인 리소스에 연결됩니다. 그것은 또한 제공합니다 매우 효율적이면서도 분산화된 오프체인 컴퓨팅 리소스에 액세스할 수 있습니다. 일반적으로, DON은 메인 체인에서의 작업을 지원합니다. 그 목표는 안전하고 유연한 서비스를 제공하는 것입니다.온체인 및 오프체인 계산을 결합한 하이브리드 smart contracts 외부 리소스에 대한 연결. 우리는 DONs에서 위원회를 사용하더라도 Chainlink 자체가 본질적으로 허가가 없는 상태로 유지됩니다. DONs는 무허가형의 기초 역할을 합니다. 노드가 함께 모여 사용자 정의 oracle 네트워크를 구현할 수 있는 프레임워크 허가되거나 허가되지 않을 수 있는 노드 포함에 대한 자체 체제. DONs를 기반으로 Chainlink 2.0에서는 7개 분야의 발전에 집중할 계획입니다. 핵심 영역: 하이브리드 smart contracts, 복잡성 추상화, 확장성, 기밀성, 거래 주문 공정성, 신뢰 최소화 및 인센티브 기반(암호경제적) 보안. 이 백서 소개에서는 분산화의 개요를 제시합니다. 섹션 1.1의 Oracle Networks와 섹션 1.2의 7가지 주요 혁신 영역. 섹션 1.3에서 이 문서의 나머지 부분의 구성을 설명합니다. 1.1 분산형 오라클 네트워크 분산형 Oracle 네트워크는 기능을 향상하고 확장하도록 설계되었습니다. 대상 blockchain 또는 다음 기능을 통한 메인 체인의 smart contract 기본적으로 사용할 수 없습니다. 그들은 다음의 세 가지 기본 리소스를 제공하여 이를 수행합니다. 컴퓨팅 시스템: 네트워킹, 저장 및 계산. DON은(는) 다음을 제공하는 것을 목표로 합니다. 강력한 기밀성, 무결성 및 가용성 속성을 지닌 이러한 리소스는1 책임감도 그렇고. DONs는 특정 목적을 달성하기 위해 협력하는 oracle 노드 위원회로 구성됩니다. 직업을 갖거나 지속적인 서비스를 제공하기 위해 장기적인 관계 구축을 선택합니다. 클라이언트에게. DON은 blockchain에 구애받지 않는 방식으로 설계되었습니다. 그들은 다음과 같은 역할을 할 것을 약속합니다. 애플리케이션 개발자가 오프체인 지원을 생성할 수 있는 강력하고 유연한 도구입니다. 지원되는 메인 체인의 smart contracts. DON의 기능을 실현하는 두 가지 유형의 기능: 실행 파일 및 어댑터. 실행 파일은 DON에서 분산 방식으로 지속적으로 실행되는 프로그램입니다. 메인체인 자산을 직접 저장하지는 않지만 고성능 및 기밀 수행 능력을 포함한 중요한 이점이 있습니다. 계산. 실행 파일은 DON에서 자율적으로 실행되며 결정론적 수행을 수행합니다. 운영. DON을 외부 리소스에 연결하는 어댑터와 함께 작동합니다. 실행 파일에 의해 호출될 수 있습니다. DONs에 대해 우리가 구상한 어댑터는 오늘 Chainlink의 외부 어댑터 일반화. 기존 어댑터 중 일반적으로 데이터 소스에서만 데이터를 가져오며 어댑터는 양방향으로 작동할 수 있습니다. 안으로 DONs, 그들은 추가로 DON 노드의 공동 계산을 활용하여 다음을 달성할 수 있습니다. 개인 정보 보호 소비를 위한 보고서 암호화와 같은 추가 기능 실행 파일. DON의 기본 작동에 대한 이해를 제공하기 위해 그림 1은 개념적으로 DON은(는) blockchain에 보고서를 보내는 데 사용되어 기존의 oracle 기능을 달성할 수 있습니다. DONs는 그 이상의 많은 추가 기능을 제공할 수 있습니다. 1정보 보안의 "CIA 3대 요소" [123, p. 26, §2.3.5].Chainlink의 기존 네트워크. 예를 들어, 그림 1의 일반적인 구조 내에서, 실행 파일은 가져온 자산 가격 데이터를 DON에 기록할 수 있습니다. 예를 들어 보고서의 후행 평균을 계산합니다. 그림 1: 분산형 Oracle 네트워크가 기본 oracle 기능(예: 오프체인 데이터를 계약서에 전달)을 실현하는 방법을 예로 보여주는 개념적 그림. 안 실행 파일은 어댑터를 사용하여 오프체인 데이터를 가져와서 계산하고 출력을 보냅니다. 다른 어댑터를 통해 대상 blockchain에 연결합니다. (어댑터는 DON, 작은 파란색 상자로 표시됩니다. 화살표는 이에 대한 데이터 흐름 방향을 나타냅니다. 특정 예.) 실행 파일은 추가로 로컬 DON을 읽고 쓸 수 있습니다. 상태를 유지하고/하거나 다른 실행 파일과 통신하기 위한 저장소입니다. 여기에 제시된 DONs의 유연한 네트워킹, 계산 및 저장 기능을 통해 다양한 새로운 기능을 사용할 수 있습니다. 응용 프로그램. DONs의 주요 이점은 새로운 blockchain 서비스를 부트스트랩하는 기능입니다. DONs 기존 oracle 네트워크가 서비스 애플리케이션을 신속하게 구축할 수 있는 수단입니다. 이를 위해서는 오늘날 특수 목적으로 구축된 네트워크를 구축해야 합니다. 우리는 여러 가지를 제공합니다 섹션 4에 그러한 적용 사례가 나와 있습니다. 섹션 3에서는 DON에 대한 자세한 내용을 제공하고 해당 기능을 설명합니다. 개발자와 사용자에게 제공되는 인터페이스의 용어입니다. 1.2 7가지 주요 설계 목표 여기서는 위에서 열거한 7가지 핵심 초점을 간략하게 검토해 보겠습니다. Chainlink, 즉:하이브리드 smart contracts: Chainlink에 대한 우리 비전의 핵심은 보안이라는 아이디어입니다. smart contracts에서 온체인 및 오프체인 구성 요소를 결합합니다. 우리는 계약을 참조 이 아이디어를 하이브리드 smart contract 또는 하이브리드 계약으로 실현합니다.2 블록체인은 분산형 서비스에서 두 가지 중요한 역할을 수행하고 있으며 앞으로도 계속 그럴 것입니다. 생태계: 둘 다 암호화폐 소유권이 표현되는 장소입니다. 분산형 서비스를 위한 강력한 기반입니다. 따라서 스마트 계약은 체인에서 표현되거나 실행되어야 하지만 온체인 기능은 심각하게 제한됩니다. 순전히 온체인 계약 코드는 느리고, 비용이 많이 들고, 고립되어 있어 실제 세계의 이점을 누릴 수 없습니다. 다양한 형태의 기밀 계산, (의사)무작위성 생성 등 체인에서 본질적으로 달성할 수 없는 다양한 기능과 데이터 광부 / validator 조작 등에 대한 반대 따라서 smart contracts가 잠재력을 최대한 실현하려면 smart contracts가 필요합니다. 온체인 부분(일반적으로 SC로 표시)의 두 부분으로 구성됩니다. 그리고 DON에서 실행되는 실행 파일인 오프체인 부분(일반적으로 실행). 목표는 다음과 같은 온체인 기능의 안전한 구성을 달성하는 것입니다. DONs가 제공하고자 하는 다양한 오프체인 서비스. 두 부분이 함께 하이브리드 계약을 맺습니다. 우리는 그림 2에 개념적으로 아이디어를 제시합니다. 이미 오늘, Chainlink 데이터 피드 및 VRF와 같은 서비스3는 다른 방법으로는 달성할 수 없는 기능을 제공합니다. smart contract 애플리케이션은 DeFi에서 공정하게 생성된 NFT에 이르기까지 분산형 보험에 이르기까지 보다 일반적인 프레임워크를 향한 첫 번째 단계입니다. Chainlink 서비스로 이 백서의 비전에 따라 더 많은 성능을 확장하고 성장시킵니다. 모든 blockchain에 걸쳐 smart contract 시스템의 성능을 발휘하게 됩니다. 이 백서에 있는 다른 6가지 주요 초점은 서비스에서 작동하는 것으로 볼 수 있습니다. 첫째, 하이브리드 계약 중 가장 중요한 것 중 하나입니다. 이러한 초점에는 가시적인 제거가 포함됩니다. 하이브리드 계약으로 인한 복잡성으로 인해 추가적인 오프체인 서비스가 생성됩니다. 더욱 강력한 하이브리드 계약을 구축하고, 신뢰 최소화의 경우 하이브리드 계약을 통해 달성된 보안 속성을 강화합니다. 우리는 아이디어를 떠난다 논문의 대부분에 걸쳐 암묵적으로 혼합 계약이 존재하지만, DON이 포함된 MAINCHAIN 로직은 하이브리드 계약으로 볼 수 있습니다. 복잡성 추상화: DON은 분산화를 사용하도록 설계되었습니다. 종종 복잡한 기계를 추상화하여 개발자와 사용자가 쉽게 사용할 수 있는 시스템 DONs의 강력하고 유연한 서비스를 지원합니다. 기존 Chainlink 서비스 이미 이 기능이 있습니다. 예를 들어, 오늘날 Chainlink의 데이터 피드는 개발자가 프로토콜 수준의 세부 사항에 대해 걱정할 필요가 없는 온체인 인터페이스를 제공합니다. 2온체인/오프체인 계약 구성에 대한 아이디어는 이전에 다양한 제약 조건에서 나타났습니다. 양식(예: 레이어 2 시스템, TEE 기반 blockchains [80] 등)을 지원하고 일반화하는 것이 우리의 목표입니다. 이러한 접근 방식을 통해 오프체인 데이터 액세스 및 기타 키를 포괄할 수 있는지 확인합니다. oracle 서비스. 3Chainlink 서비스는 다음을 통해 제공되는 다양한 분산형 서비스와 기능으로 구성됩니다. 네트워크. 다양한 oracle 네트워크로 구성된 수많은 노드 운영자가 제공합니다. 생태계 전반에 걸쳐.그림 2: 온체인/오프체인 계약 구성을 나타내는 개념적 그림. 에이 하이브리드 smart contract 3⃝은 두 가지 보완적인 구성 요소, 즉 온체인으로 구성됩니다. blockchain에 상주하는 구성 요소 SC 1⃝ 및 오프 체인 구성 요소 exec 2⃝ DON에서 실행됩니다. DON은 두 구성요소 사이의 브리지 역할도 합니다. 웹 서비스 등 오프체인 리소스와 하이브리드 컨트랙트를 연결하는 등 blockchains, 분산형 저장소 등 분산된 노드 세트. DONs는 Chainlink이 개발자에게 추상화 계층을 제공할 수 있는 서비스 범위 높은 수준의 서비스를 위한 간소화된 인터페이스를 제공합니다. 이 접근 방식을 강조하는 몇 가지 응용 사례를 섹션 4에 제시합니다. 예를 들어 우리는 DONs를 보안 미들웨어의 한 형태로 사용하는 기업을 구상합니다. 레거시 시스템을 blockchain에 연결하세요. (섹션 4.2 참조) DON을 사용하면 일반적인 blockchain 역학(수수료, 재구성 등)의 복잡성이 추상화됩니다. 그것은 또한 특정 blockchain의 기능을 추상화하여 기업이 기존 시스템을 계속 확장되는 blockchain 시스템 어레이에 연결할 수 있도록 합니다. 이러한 시스템 또는 더 일반적으로는 분산형 시스템 개발에 대한 전문 지식이 필요합니다. 궁극적으로 우리의 목표는 Chainlink에 의해 달성된 추상화 수준을 높이는 것입니다. 우리가 분산형 메타레이어라고 부르는 것을 구현하는 지점까지 말이죠. 그러한 층 모든 계층의 개발자에 대한 온체인/오프체인 구분을 추상화합니다. 및 DApp 사용자를 통해 분산형 서비스를 원활하게 생성하고 사용할 수 있습니다.개발 프로세스를 단순화하기 위해 개발자는 메타 레이어의 DApp 기능을 통합 머신 모델의 가상 애플리케이션으로 지정할 수 있습니다. 그들은 할 수 있었다 그런 다음 분산형 금속층 컴파일러를 사용하여 DApp을 자동으로 인스턴스화합니다. blockchains, DONs에 걸쳐 상호 운용되는 분산 기능 세트 및 외부 서비스. (이러한 외부 서비스 중 하나는 엔터프라이즈 시스템일 수 있으므로 레거시 엔터프라이즈 시스템과 관련된 애플리케이션에 메타레이어를 유용하게 만듭니다.) 컴파일은 최신 컴파일러 및 소프트웨어 개발 키트(SDK)와 유사합니다. 이기종 하드웨어의 잠재력을 최대한 활용하는 일반 프로그래머 지원 범용 CPU와 GPU와 같은 특수 하드웨어로 구성된 아키텍처, 기계 학습 가속기 또는 신뢰할 수 있는 엔클레이브. 그림 3은 이 아이디어를 개념적 수준으로 제시합니다. 하이브리드 smart contract는 이 비전과 메타 계약이라고 부르는 개념을 향한 첫 번째 단계입니다. 메타 계약은 분산형 시스템에 코딩된 애플리케이션입니다. 메타레이어는 온체인 로직(smart contracts)뿐만 아니라 오프체인 계산 및 다양한 blockchains와 기존 오프체인 간의 연결을 암시적으로 포함합니다. 서비스. 언어 및 컴파일러 지원의 필요성을 고려하여 새로운 보안 모델 및 서로 다른 기술의 개념적, 기술적 조화는 실현되지만, 진정한 분산형 금속층을 구축하는 것은 우리가 오랫동안 열망해 온 야심찬 목표입니다. 시간 지평선. 그럼에도 불구하고 읽는 동안 명심해야 할 유용한 이상적인 모델입니다. 이 문서는 여기에 자세히 설명되어 있지 않지만 향후 작업에서 집중할 계획입니다. Chainlink. 스케일링: 진화하는 디자인에서 가장 중요한 목표는 Chainlink 네트워크는 blockchain 생태계의 증가하는 확장 요구 사항을 충족합니다. 기존 무허가형 환경에서는 네트워크 정체가 반복적으로 문제가 되면서 blockchains [86], 새롭고 더 성능이 뛰어난 blockchain 디자인이 사용되기 시작했습니다. 예를 들어 [103, 120, 203]과 보완적인 레이어 2 스케일링 기술(예: [5, 12, 121, 141, 169, 186, 187]. Oracle 서비스는 지연 시간과 처리량을 달성해야 합니다. 온체인 수수료를 최소화하면서 이러한 시스템의 성능 요구 사항을 충족합니다. (예: 가스 비용) 계약 운영자와 일반 사용자 모두에게 적용됩니다. DONs, Chainlink 사용 기능은 더 나아가 순수한 웹 기반 시스템에 충분히 높은 성능을 제공하는 것을 목표로 합니다. DONs는 blockchains와 결합된 빠른 위원회 기반 또는 무허가 합의 프로토콜을 사용하여 많은 성능 향상을 얻습니다. 그들은 지원합니다. 우리는 서로 다른 구성을 가진 많은 DON이 병렬로 실행될 것으로 예상합니다. 다양한 DApp과 사용자는 기본 합의 선택에서 트레이드오프를 탐색할 수 있습니다. 그들의 신청 요구 사항에 따라. DON은 사실상 레이어 2 기술로 볼 수 있습니다. 우리는 그 중에서 다른 서비스에서는 DONs가 TEF(Transaction Execution Framework)를 지원합니다. DON 및 oracle을 다른 고성능 제품과 효율적으로 통합할 수 있습니다. 레이어 2 시스템(예: rollups, 달성하기 위해 오프체인 트랜잭션을 번들로 묶는 시스템) 성능 개선. 섹션 6에서 TEF를 소개합니다.
그림 3: 분산형 금속층의 이상적인 구현을 보여주는 개념적 그림. 에 대한 개발의 용이성을 위해 개발자는 분홍색으로 강조된 DApp을 가상 애플리케이션으로 지정합니다. 통합 기계 모델에 적용. 분산형 메탈레이어 컴파일러는 해당 상호 운용 기능을 자동으로 생성합니다: smart contracts(표시됨) SC별), DONs의 논리(exec로 표시됨), 대상 외부 서비스에 연결하는 어댑터 등은 노란색으로 강조 표시됩니다. 그림 4는 DONs가 blockchain(smart contract) 스케일링을 어떻게 개선하는지 개념적으로 보여줍니다. 거래 및 oracle-보고서 처리를 온체인이 아닌 오프체인에 집중함으로써 체인. 계산의 주요 위치가 바뀌면 트랜잭션 대기 시간이 줄어들고 거래 처리량을 높이는 동시에 수수료를 부과합니다. 기밀성: 블록체인은 smart contracts 및 그들이 실현하는 애플리케이션에 대해 전례 없는 투명성을 제공합니다. 그러나 투명성과 기밀성 사이에는 기본적인 긴장이 있습니다. 예를 들어, 오늘날 사용자의 분산형 교환 거래는그림 4: 분산형 Oracle 네트워크가 어떻게 성능을 향상시키는지를 보여주는 개념적 그림 blockchain 활성화된 smart contract의 크기 조정. 그림 A ⃝는 기존의 oracle을 보여줍니다. 건축. 거래는 oracle 보고서와 마찬가지로 blockchain로 직접 전송됩니다. 따라서 노란색으로 강조 표시된 blockchain은 트랜잭션 처리의 주요 위치입니다. 그림 B⃝는 blockchain에 대한 계약을 지원하기 위해 DON을 사용하는 것을 보여줍니다. A DON 실행 파일은 외부 시스템의 데이터와 함께 트랜잭션을 처리하고 전달합니다. 결과(예: 번들 트랜잭션 또는 트랜잭션 효과로 인한 계약 상태 변경)를 blockchain에 보냅니다. 따라서 노란색으로 강조 표시된 DON가 주요 트랜잭션 처리를 위한 위치입니다. 활동은 체인에 기록되므로 교환 활동을 쉽게 모니터링할 수 있을 뿐만 아니라 사용자의 금융 거래를 공개적으로 표시합니다. 마찬가지로 데이터가 스마트로 전달됩니다. 계약은 체인에 남아 있습니다. 이를 통해 이러한 데이터를 편리하게 감사할 수 있지만 다음과 같은 역할을 합니다. smart contract에 민감하거나 민감한 데이터를 제공하려는 데이터 제공자에게는 방해가 됩니다. 독점 데이터. 우리는 oracle 네트워크가 차세대 촉매 역할을 할 것이라고 믿습니다. blockchains의 타고난 투명성과 새로운 기밀 보호 기능을 결합한 시스템입니다. 이 문서에서는 세 가지 주요 접근 방식을 사용하여 이를 수행하는 방법을 보여줍니다. • 기밀 유지 어댑터: 계획된 배포가 포함된 두 가지 기술 Chainlink의 네트워크 DECO [234] 및 Town Crier [233]에서 oracle 노드를 활성화합니다. 사용자 개인정보와 데이터를 보호하는 방식으로 오프체인 시스템에서 데이터를 검색합니다. 기밀성. 이는 DONs용 어댑터 설계에서 중요한 역할을 합니다. (이 두 기술에 대한 자세한 내용은 섹션 3.6.2를 참조하세요.) • 기밀 계산: DONs는 blockchains에 의존하지 않도록 자신의 계산을 숨길 수 있습니다. 안전한 다자간 계산 및/또는 신뢰할 수 있는 실행 환경을 사용하면 DON 노드에서 더 강력한 기밀성이 가능합니다. 자신이 볼 수 없는 데이터에 대해 계산합니다.
• 기밀 레이어 2 시스템 지원: TEF는 다양한 레이어 2 시스템을 지원하도록 설계되었으며, 그 중 다수는 영지식 증명을 사용하여 다음을 제공합니다. 다양한 형태의 거래 기밀성. 섹션 3에서 이러한 접근 방식을 논의합니다(섹션 6, 부록 B.1 및 부록 B.2의 추가 세부정보 포함). 그림 5는 기밀 유지 어댑터를 통해 민감한 데이터가 외부 소스에서 smart contract로 어떻게 흐를 수 있는지에 대한 개념적 보기를 제공합니다. DON의 기밀 계산. 그림 5: DON의 기밀 유지 작업에 대한 개념 다이어그램 민감한 데이터(노란색으로 강조 표시됨) 웹의 민감한 소스 데이터(검은색 원) 서버는 기밀 유지 어댑터(파란색, 이중 화살표 선)를 사용하여 DON로 추출됩니다. DON는 이러한 어댑터로부터 파생된 데이터(빈 원)를 수신합니다. 민감한 소스에 기능이나 비밀 공유 등을 적용한 결과 데이터. DON의 실행 파일은 파생된 데이터에 기밀 계산을 적용할 수 있습니다. 보고서(이중 원)를 구성하여 어댑터를 통해 blockchain로 보냅니다. 우리는 기밀 데이터를 처리하는 강력한 도구가 전체를 열어줄 것이라고 믿습니다. 응용 범위. 그 중에는 민간 분산형(및 중앙집중형) 금융, 분산형 신원, 신용 기반 온체인 대출, 보다 효율적이고 섹션 4에서 논의한 바와 같이 사용자 친화적인 고객 파악 및 인증 프로토콜. 거래의 주문 공정성: 오늘의 blockchain 디자인에는 약간 더러운 부분이 있습니다. 공개 비밀: 일시적으로 중앙 집중화되어 있습니다. 광부와 validators는 거래를 주문할 수 있습니다.그들이 선택한 행동. 거래 순서는 다음과 같이 사용자가 조작할 수도 있습니다. 그들이 지불하는 네트워크 수수료의 함수(예: Ethereum의 가스 가격) 및 일부 빠른 네트워크 연결을 활용하여 확장합니다. 그러한 조작은 다음과 같은 경우에 발생할 수 있습니다. 예를 들어, 채굴자와 같은 전략적 행위자가 참여하는 선행 실행(front-running) 형태를 취합니다. 사용자의 거래를 관찰하고 자신의 악용 거래를 이전 거래에 삽입합니다. 동일한 블록에 위치 - 사용자 거래에 대한 사전 지식을 활용하여 사용자로부터 효과적으로 돈을 훔칩니다. 예를 들어, 봇이 구매 주문을 할 수 있습니다. 사용자 앞에. 그러면 이는 다음으로 인한 자산 가격 상승을 활용할 수 있습니다. 사용자의 거래. 일반 사용자에게 해를 끼치는 일부 봇의 선행 실행(고빈도와 유사) 월스트리트에서의 거래는 이미 널리 퍼져 있으며 관련 내용이 잘 문서화되어 있습니다 [90] 백러닝 [159] 및 [195]을 모방한 자동 트랜잭션과 같은 공격. 채굴자들의 주문 착취를 체계화하려는 제안도 최근에 표면화되었습니다([110]). rollups와 같은 레이어 2 기술은 문제를 해결하지 못하고 단지 재중앙화만 합니다. 주문하여 rollup을 생성하는 개체의 손에 넘겨줍니다. 우리의 목표 중 하나는 Chainlink에 Fair Sequencing이라는 서비스를 도입하는 것입니다. 서비스 (FSS) [137]. FSS는 smart contract 디자이너가 공정한 주문을 보장하도록 돕습니다. 트랜잭션을 방지하고 사용자 트랜잭션은 물론 oracle 보고서 전송과 같은 기타 유형의 트랜잭션에 대한 선행 실행, 역실행 및 관련 공격을 방지합니다. FSS [144]에 도입된 엄격하고 일시적인 질서 공정성 개념과 같은 아이디어를 DON에서 구현할 수 있습니다. 부수적인 이점으로 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 contracts 및 기타 oracle 종속 시스템에 대한 신뢰할 수 있는 지원 계층 분산화, 암호화 도구 및 암호화 경제 보장을 통해. DON 자체는 분산되어 있으며 사용자는 사용 가능한 DON 중에서 선택할 수 있습니다. 추가 DON을 운영하거나 생성하려는 메인 체인을 지원합니다. 그들이 신뢰하는 노드 위원회를 통해. 그러나 일부 애플리케이션, 특히 smart contracts, Chainlink 사용자의 경우 DON이 지원하는 메인 체인을 더 신뢰할 수 있는 것으로 취급하는 신뢰 모델을 선호합니다. DON 자체보다. 그러한 사용자를 위해 우리는 이미 Chainlink 네트워크의 아키텍처 계약을 가능하게 하는 다양한 메커니즘 DONs가 제공하는 보안 보증을 강화하기 위해 메인 체인에 동시에 데이터 소스가 손상될 가능성에 대비한 보호 조치도 시행합니다. DON이 데이터를 얻는 웹 서버와 같은 것입니다. 우리는 섹션 7에서 이러한 메커니즘을 설명합니다. 이는 다섯 가지 주요 제목으로 분류됩니다. • 데이터 소스 인증: 데이터 공급자가 디지털 서명을 할 수 있게 해주는 도구 데이터를 수집하여 원산지와 원산지 간의 관리 사슬을 강화합니다. 의존 계약. • DON 소수 보고서: DON 노드의 소수 하위 집합에서 발행한 플래그입니다. DON에서 대부분의 불법 행위를 관찰했습니다. • 가드레일: 비정상적인 조건을 감지하고 일시 중지하는 메인 체인의 로직 또는 계약 실행을 중단합니다(또는 다른 수정 조치를 호출합니다). • 신뢰가 최소화된 거버넌스: 점진적인 릴리스 업데이트를 사용하여 커뮤니티 검사를 촉진하고 분산형 긴급 개입을 통해 신속한 조치를 취합니다. 시스템 장애에 대한 대응. • 분산형 엔터티 인증: 공개 키 인프라(PKI)를 사용하여 다음을 수행합니다. Chainlink 네트워크의 엔터티를 식별합니다. 그림 7은 신뢰 최소화 목표의 개념적 개략도를 나타냅니다. 인센티브 기반(암호경제적) 보안: oracle 노드 전반에 걸쳐 보고서 생성을 분산화하면 일부 노드가 손상된 경우에도 보안을 보장할 수 있습니다.
그림 7: Chainlink의 신뢰 최소화 목표에 대한 개념적 묘사 DON 및 웹과 같은 데이터 소스의 올바른 동작에 대한 사용자의 요구를 최소화합니다. 서버. 그림의 노란색 강조 표시는 신뢰 최소화 위치를 나타냅니다: DON 및 개별 또는 소수의 웹 서버 세트. 분홍색 강조 표시는 시스템 구성 요소를 나타냅니다. 가정에 의해 매우 신뢰할 수 있는 것: blockchain에 대한 계약 및 대다수 웹 서버의 수, 즉 웹 서버 전체를 의미합니다. 하지만 마찬가지로 중요한 것은 노드가 올바르게 행동할 수 있는 재정적 인센티브를 갖도록 보장하는 것입니다. 스테이킹, 즉 노드가 LINK 예치금을 제공하고 슬래싱하도록 요구 (압수) 잘못된 행동이 있을 경우 이러한 예금은 Chainlink에서 핵심적인 역할을 할 것입니다. 이미 다수의 blockchain에서 사용되고 있는 중요한 인센티브 디자인입니다. 예를 들어 [81, 103, 120, 204]. 그러나 Chainlink에 스테이킹하는 것은 독립 실행형의 staking과 매우 다르게 보입니다. blockchains. blockchains에 스테이킹하는 것은 합의에 대한 공격을 방지하는 것을 목표로 합니다. 그것은 Chainlink의 다른 목표: 올바른 oracle 보고서를 적시에 전달하는 것입니다. oracle 네트워크를 위해 잘 설계된 staking 시스템은 뇌물 수수와 같은 공격을 렌더링해야 합니다. 목표가 높은 smart contract인 경우에도 적에게는 이익이 되지 않습니다. 금전적 가치. 본 논문에서는 세 가지 핵심을 통해 Chainlink의 staking에 대한 일반적인 접근 방식을 제시합니다. 혁신:1. 기존에서 간과된 공격을 포괄하는 강력한 적대 모델 접근합니다. 한 가지 예는 우리가 장래 뇌물 수수라고 부르는 것입니다. 이것은 다음과 같은 형태입니다. 어떤 노드가 조건부로 뇌물을 받는지 결정하는 뇌물 수수. staking 메커니즘이 선택한 노드에 미리 보장된 뇌물을 제공합니다. 특정 역할에 대해 무작위입니다(예: 보고서 심사 실행). 2. 초선형 staking 영향, 즉 성공하려면 적의 예산이 모든 oracle의 예금을 합친 것보다 $B 더 커야 함을 비공식적으로 의미합니다. 노드. 보다 정확하게는 n의 함수로서 \(B(n) ≫\)dn이 각각 고정 입금액 $d를 갖는 n oracle 노드의 네트워크(보다 공식적으로는 \(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에서 보안 모델과 표기법을 제시하고 분산형 보안의 개요를 설명합니다. 섹션 3의 Oracle Network API. 섹션 4에서는 다음과 같은 여러 가지 예를 제시합니다. DONs가 매력적인 배포 플랫폼을 제공하는 애플리케이션입니다. 독자는 다음을 수행할 수 있습니다. 지금까지 읽으면 논문의 주요 개념 대부분을 배울 수 있습니다. 문서의 나머지 부분에는 더 자세한 내용이 포함되어 있습니다. 우리는 공정한 순서를 설명합니다 섹션 5의 서비스(FSS) 및 섹션 6의 거래 실행 프레임워크(TEF). 섹션 7에서는 신뢰 최소화에 대한 접근 방식을 설명합니다. 중요한 DON 배포 요구 사항, 즉 기능의 점진적 출시, 동적 원장 멤버십 및 섹션 8의 책임. 마지막으로 섹션 9에서 다음을 제공합니다. 인센티브 디자인에 대한 우리의 개발 접근 방식에 대한 개요입니다. 섹션 10에서 결론을 내린다. 이 문서의 개념에 익숙하지 않은 독자를 돕기 위해 우리는 부록 A에 용어집을 제공합니다. DON 인터페이스에 대한 자세한 내용을 제시합니다. 및 기능은 부록 B에 나와 있으며 부록 C에는 몇 가지 어댑터 예시가 나와 있습니다. 부록 D에서는 신뢰가 최소화된 데이터 소스에 대한 암호화 기본 요소를 설명합니다. 기능 서명이라는 인증을 도입하고 이산화된 기능 서명이라는 새로운 변형을 도입합니다. 우리는 위원회와 관련된 몇 가지 고려 사항을 논의합니다. 부록 F의 DON에 대한 선택
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 노드 세트에 의해 실행됩니다. 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: 그 목적은 blockchain 및 기타 시스템을 지원하는 것입니다. 블록체인은, 물론 신뢰할 수 있는 원장을 실현하는 한 가지 방법이지만 다른 방법도 있습니다. 우리는 기대한다 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을 사용하지 않더라도 L에 기록됩니다.2.3 표기법 원장을 실행하는 n oracle 노드 집합을 O = {Oi}n으로 나타냅니다. 나는 = 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 표기법을 사용하여 다음을 수행합니다. 그러한 계약을 나타냅니다. 우리는 일반적으로 DON이 단일 메인 체인 MAINCHAIN을 지원한다고 가정하지만, 섹션 4의 예에서 볼 수 있듯이 여러 체인을 지원할 수 있습니다. A DON은 MAINCHAIN에서 여러 의존 계약을 지원할 수 있으며 일반적으로 지원할 것입니다. ( 위에서 언급했듯이 DON은 blockchain이 아닌 서비스를 대안으로 지원할 수 있습니다.) 2.4 신뢰 모델에 대한 참고 사항 위에서 언급했듯이 DON은 위원회 기반 합의 프로토콜 위에 구축될 수 있으며, 그들은 일반적으로 그러한 프로토콜을 사용할 것으로 예상합니다. 강력한 주장이 많다. 위원회 기반 또는 무허가 blockchains의 두 가지 대안 중 하나는 다음을 제공합니다. 다른 것보다 보안이 더 강력합니다. 위원회 기반 보안과 무허가 보안의 보안을 인식하는 것이 중요합니다. 분산형 시스템은 비교할 수 없습니다. PoW 또는 PoS 침해 blockchain 51% 공격을 통해 적이 일시적으로 대부분의 자원을 획득해야 하며 예를 들어 PoW 시스템에서 hash 전력을 임대함으로써 잠재적으로 익명으로 가능합니다. 그러한 실제로 공격은 이미 여러 blockchains [200, 34]에 영향을 미쳤습니다. 대조적으로, 위원회 기반 시스템을 손상시키는 것은 노드의 임계값(일반적으로 1/3)을 손상시키는 것을 의미합니다. 여기서 노드는 공개적으로 알려지고 리소스가 풍부하며 그리고 신뢰할 수 있는 실체. 반면에 위원회 기반 시스템(및 무허가형 "하이브리드") 위원회를 지원하는 시스템)은 엄격하게 규정된 것보다 더 많은 기능을 지원할 수 있습니다.미션리스 시스템. 여기에는 다음과 같은 지속적인 비밀을 유지하는 기능이 포함됩니다. 서명 및/또는 암호화 키는 우리 설계의 한 가지 가능성입니다. 우리는 DON이 원칙적으로 위원회 기반 또는 무허가 합의 프로토콜 및 DON 배포자는 궁극적으로 채택을 선택할 수 있습니다. 어느 쪽이든 접근합니다. 신뢰 모델 강화: 오늘날 Chainlink의 주요 기능은 사용자가 다음을 수행할 수 있다는 것입니다. 논의된 대로 성능 기록의 분산된 기록을 기반으로 노드를 선택합니다. 섹션 3.6.4. 섹션 9에서 소개하는 staking 메커니즘과 암시적 인센티브 프레임워크는 함께 광범위하고 엄격한 메커니즘 설계를 구성합니다. DONs의 보안을 측정할 수 있는 크게 확장된 기능을 사용자에게 제공하는 프레임워크입니다. 이 동일한 프레임워크를 통해 DONs 자체도 가능해집니다. 참여 노드에 다양한 보안 요구 사항을 적용하고 운영을 보장합니다. 강력한 신뢰 모델 내에서. DONs에 대해 이 문서에 설명된 도구를 사용하여 규제 요구 사항 준수와 같은 특별한 신뢰 모델 요구 사항을 적용하는 것도 가능합니다. 에 대한 예를 들어, 섹션 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.
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-
능력 여기에서는 간단하지만 강력한 측면에서 DON의 기능을 간략하게 설명합니다. 인터페이스를 실현하도록 설계되었습니다. DON의 애플리케이션은 실행 파일과 어댑터로 구성됩니다. 실행 파일은 핵심 논리가 smart contract과 유사한 결정론적 프로그램인 프로그램입니다. 실행 파일에는 항목을 호출하는 프로그램과 함께 제공되는 여러 시작 프로그램도 있습니다. 미리 결정된 이벤트가 발생할 때 실행 파일 논리의 지점(예: 특정 시간) (크론 작업과 같은), 가격이 임계값을 초과하는 경우 등 - 키퍼와 매우 유사합니다(섹션 3.6.3 참조). 어댑터는 오프체인 리소스에 대한 인터페이스를 제공하며 다음에 의해 호출될 수 있습니다. 실행 파일의 개시자 또는 핵심 논리입니다. 그들의 행동은 그것에 달려 있을 수 있기 때문에 외부 리소스의 경우 개시자 및 어댑터가 비결정적으로 동작할 수 있습니다. 우리는 DON 개발자 인터페이스와 실행 파일의 기능을 설명하고 컴퓨팅 시스템을 특성화하는 데 일반적으로 사용되는 세 가지 리소스인 네트워킹, 컴퓨팅, 스토리지 측면에서 어댑터를 설명합니다. 우리는 이들 각각에 대한 간략한 개요를 제공합니다 아래 리소스를 참조하고 부록 B에 자세한 내용을 제공하세요.
3.1 네트워킹 어댑터는 DON에서 실행되는 실행 파일을 보내고 전송할 수 있는 인터페이스입니다. off-DON 시스템에서 데이터를 수신합니다. 어댑터는 다음의 일반화로 볼 수 있습니다. 현재 Chainlink에서 사용되는 어댑터 [20]. 어댑터는 양방향일 수 있습니다. 그냥 끌어올 수는 없지만 DON에서 웹 서버로 데이터를 푸시할 수 있습니다. 그들은 또한 활용할 수도 있습니다 분산 프로토콜 및 보안 다자간 보안과 같은 암호화 기능 계산. 그림 9: DON1로 표시되는 DON을 DON2로 표시되는 또 다른 DON, blockchain(메인 체인) 및 해당 리소스를 포함한 다양한 리소스와 연결하는 어댑터 멤풀, 외부 저장소, 웹 서버 및 IoT 장치(웹 서버를 통해). 어댑터가 생성될 수 있는 외부 리소스의 예가 표시됩니다. 그림 9에서. 여기에는 다음이 포함됩니다. • 블록체인: 어댑터는 blockchain에 트랜잭션을 보내는 방법을 정의할 수 있으며 블록, 개별 트랜잭션 또는 기타 상태를 읽는 방법. 어댑터 blockchain의 mempool에 대해서도 정의할 수 있습니다. (섹션 3.5 참조) • 웹 서버: 어댑터는 데이터를 검색할 수 있는 API를 정의할 수 있습니다. 특별히 적합하지 않은 레거시 시스템을 포함한 웹 서버에서 DONs와 인터페이스합니다. 이러한 어댑터에는 데이터를 전송하는 API도 포함될 수 있습니다. 그런 서버. DON이 연결되는 웹 서버는 게이트웨이 역할을 할 수 있습니다. IoT(사물 인터넷) 장치와 같은 추가 리소스에 연결됩니다.• 외부 저장소: 어댑터는 저장소를 읽고 쓰는 방법을 정의할 수 있습니다. 분산 파일 시스템[40, 188] 또는 클라우드와 같은 DON 외부 서비스 저장. • 기타 DONs: 어댑터는 DONs 간에 데이터를 검색하고 전송할 수 있습니다. DONs의 초기 배포에는 일련의 빌딩 블록이 포함될 것으로 예상됩니다. 일반적으로 사용되는 외부 리소스에 대한 어댑터를 추가로 허용하고 DON 특정 DON 노드에서 게시할 어댑터입니다. smart contract 개발자가 어댑터를 작성함에 따라 오늘 우리는 그들이 이 고급 기술을 사용하여 훨씬 더 강력한 어댑터를 구축할 것으로 기대합니다. 기능. 우리는 궁극적으로 사용자가 새로운 어댑터를 생성하는 것이 가능할 것으로 기대합니다. 무허가 방식. 일부 어댑터는 DON에 의해 제어되는 외부 리소스의 지속성과 가용성을 보장하는 방식으로 구성되어야 합니다. 예를 들어 클라우드 스토리지는 다음과 같습니다. 클라우드 서비스 계정의 유지 관리가 필요합니다. 또한 DON는 다음을 수행할 수 있습니다. 사용자를 대신하여 개인 키의 분산 관리(예: [160]) 및/또는 실행 파일. 결과적으로 DON은(예: blockchain 대상에서 트랜잭션을 보내는 데 사용될 수 있는) 암호화폐와 같은 리소스를 제어할 수 있습니다. DON 어댑터에 대한 자세한 내용은 부록 B.1을 참조하세요. 예시 어댑터. 3.2 계산 실행 파일은 DON의 기본 코드 단위입니다. 실행 파일은 exec = 쌍입니다. (논리, 초기화). 여기서 로직은 다수의 지정된 항목이 있는 결정론적 프로그램입니다. points (logic1, logic2, ..., logicℓ) 및 init는 해당 개시자의 집합입니다. (init1, init2, ..., inite). 실행 파일의 논리인 DON의 전체 감사 가능성을 보장하려면 모든 입력과 출력에 기본 원장 L을 사용합니다. 따라서 예를 들어 모든 어댑터는 실행 파일에 대한 입력으로 사용되는 데이터는 먼저 L에 저장되어야 합니다. 개시자: 현재 Chainlink의 개시자는 이벤트에 따른 작업 실행을 유발합니다. Chainlink 노드 [21]. DONs의 개시자는 거의 동일한 방식으로 작동합니다. 그러나 DON 개시자는 실행 파일과 구체적으로 연결됩니다. 개시자는 의존할 수 있습니다 외부 사건이나 상태, 현재 시간, 또는 DON 상태에 대한 술어. 이벤트에 대한 의존성으로 인해 개시자는 물론 비결정적으로 동작할 수도 있습니다. (물론 어댑터도 마찬가지입니다). 개시자는 개별 DON 노드 내에서 실행할 수 있습니다. 따라서 어댑터에 의존할 필요가 없습니다. (아래 예 1을 참조하세요.) 개시자는 실행 파일을 smart contract과 구별하는 중요한 기능입니다. 실행 파일은 개시자에 대한 응답으로 실행될 수 있으므로 효과적으로 작동할 수 있습니다. 물론 확장을 통해 실행 파일을 통합하는 하이브리드 계약이 자율적으로 가능합니다. 오늘날 개시자의 한 형태는 거래를 제공하는 Chainlink Keeper입니다.oracle 보고서를 기반으로 과소담보 대출 청산 및 지정가 주문 거래 실행과 같은 smart contract 실행을 실행하는 자동화 서비스입니다. 편리하게도 DONs의 개시자를 지정하는 방법으로 볼 수도 있습니다. 실행 파일에 적용되는 서비스 계약(아래 상황을 정의함) DON에서 호출해야 합니다. 다음 예에서는 실행 파일 내에서 개시자가 작동하는 방식을 보여줍니다. 예시 1(편차로 인한 가격 피드) smart contract SC에는 새로운 것이 필요할 수 있습니다. 예를 들어 1%와 같이 상당한 변화가 있을 때마다 가격 피드 데이터(섹션 3.6.3 참조) 한 쌍의 자산(예: ETH-USD) 간의 환율. 변동성에 민감한 가격 피드는 현재 Chainlink에서 지원되지만 어떻게 지원되는지 살펴보는 것이 좋습니다. 실행 가능한 execfeed를 통해 DON에서 실현되었습니다. 실행 가능한 execfeed는 L의 가장 최근 ETH-USD 가격 r을 유지합니다. ⟨NewPrice : j, r⟩항목의 시퀀스 형태. 여기서 j는 다음과 같이 증가하는 인덱스입니다. 각 가격 업데이트. 개시자 init1은 각 노드 Oi가 현재 ETH-USD 가격을 모니터링하도록 합니다. 인덱스 j를 사용하여 가장 최근에 저장한 가격 r에서 최소 1%의 편차. 시 이러한 편차를 감지한 Oi는 다음을 사용하여 새 가격의 현재 보기 ri를 L에 기록합니다. ⟨PriceView : i, j + 1, ri⟩ 형식의 항목. 두 번째 개시자 init2는 새 가격이 포함된 PriceView 항목이 k개 이상 있을 때 발생합니다. 개별 노드에서 생성된 인덱스 j + 1의 값이 L에 누적됩니다. 그러면 init2 첫 번째 k개의 유효한 유효한 가격 보기 값 k개의 중앙값 ρ를 계산하기 위해 진입점 logic2를 호출하고 새로운 값 ⟨NewPrice : j + 1, ρ⟩을 L에 씁니다. (운영상 노드 교대로 지정작가가 될 수 있다.) 세 번째 개시자 init3은 L의 NewPrice 항목을 감시합니다. 새 보고서가 나올 때마다 ⟨NewPrice : j, r⟩가 거기에 나타나며 (j, r)을 SC에 푸시하는 진입점 logic3을 호출합니다. 어댑터를 사용하여. 앞서 언급했듯이 실행 파일은 기능 면에서 smart contract과 유사합니다. 그러나 더 높은 성능 외에도 일반적인 메인 체인 계약과 다릅니다. 두 가지 중요한 방법으로: 1. 기밀성: 실행 파일은 기밀 계산을 수행할 수 있습니다. 즉, 비밀 프로그램이 일반 텍스트 입력을 처리하거나 게시된 프로그램이 처리할 수 있습니다. 비밀 입력 데이터 또는 둘의 조합. 간단한 모델에서는 비밀 데이터가 중간 결과를 숨기고만 공개하는 DON 노드에서 액세스할 수 있습니다. MAINCHAIN에 처리 및 삭제된 값. DONs 자체에서 민감한 데이터를 숨기는 것도 가능합니다. DONs는 다음과 같은 접근 방식을 지원하기 위한 것입니다. 다자간 계산(예: [42, 157]) 및 신뢰할 수 있는 실행 환경 (TEE) [84, 133, 152, 229] 이 목적을 위해.6 6더 나아가 DON 노드와 관련하여 실행 파일 자체를 비밀로 유지하는 것도 가능합니다. 이는 오늘날 TEE를 사용하는 중요하지 않은 실행 파일에만 실용적입니다.2. 지원 역할: 실행 파일은 기본에서 smart contract을 지원하기 위한 것입니다. 체인을 교체하는 대신 실행 파일에는 다음과 같은 몇 가지 제한 사항이 있습니다. smart contract은(는) 다음을 수행하지 않습니다. (a) 신뢰 모델: 실행 파일은 다음에 의해 정의된 신뢰 모델 내에서 작동합니다. DON: 올바른 실행은 O의 정직한 행동에 달려 있습니다. (메인 그러나 체인은 DON 불법 행위에 대한 일부 가드 레일을 제공할 수 있습니다. 섹션 7.3에서 논의됨) (b) 자산 액세스: DON은 blockchain의 계정을 제어할 수 있으므로 어댑터를 통해 자산을 제어합니다. 하지만 DON은 정식으로 사용할 수 없습니다. Ether 또는 ERC20 tokens와 같은 메인 체인에서 생성된 자산을 나타냅니다. 그들의 네이티브 체인은 소유권에 대한 권위 있는 기록을 유지합니다. (c) 수명 주기: DONs는 다음과 같이 제한된 수명으로 의도적으로 유지될 수 있습니다. DONs와 소유자 간의 온체인 서비스 수준 계약에 의해 정의됩니다. 의존 계약의. 대조적으로, 블록체인은 다음과 같이 기능하도록 되어 있습니다. 영구 보관 시스템. DON 계산에 대한 자세한 내용은 부록 B.2를 참조하세요. 3.3 저장 위원회 기반 시스템인 DON은 적당한 양의 데이터를 지속적으로 저장할 수 있습니다. L에서는 무허가 blockchain보다 훨씬 저렴한 비용으로 사용할 수 있습니다. 또한 어댑터를 통해 DONs는 데이터 저장을 위해 외부 분산 시스템을 참조할 수 있습니다(예: Filecoin [85], 이를 통해 해당 시스템을 smart contract에 연결할 수 있습니다. 이 옵션은 특히 "부풀음"이라는 만연한 문제를 해결하는 수단으로 대량 데이터에 적합합니다. blockchain 시스템. 따라서 DONs는 특별히 지원되는 서비스에 사용하기 위해 데이터를 로컬 또는 외부에 저장할 수 있습니다. DON은(는) 이러한 데이터를 기밀 방식으로 추가로 사용할 수 있습니다. (1) DON 노드 전체에서 비밀 공유되거나 암호화된 데이터에 대한 컴퓨팅 안전한 다자간 계산에 적합한 방식으로 DON 노드에서 관리하는 키 또는 부분적 또는 완전 동형 암호화; 또는 (2) 신뢰할 수 있는 실행을 사용하여 보호됨 환경. 우리는 DONs가 일반적인 간단한 메모리 관리 모델을 채택할 것으로 기대합니다. 스마트 계약 시스템: 실행 파일은 자체 메모리에만 쓸 수 있습니다. 실행 파일 그러나 다른 실행 파일의 메모리에서는 읽을 수 있습니다. DON 저장소에 대한 자세한 내용은 부록 B.3을 참조하세요. 3.4 트랜잭션 실행 프레임워크(TEF) DONs는 메인 체인 MAINCHAIN(또는 여러 메인 체인)의 계약을 지원하기 위한 것입니다. TEF(Transaction-Execution Framework)에 대해 자세히 설명합니다.섹션 6에서는 효율적인 계약 실행에 대한 일반적인 목적의 접근 방식을 설명합니다. MAINCHAIN 및 DON 전반의 SC. TEF는 FSS 및 레이어-2를 지원하도록 고안되었습니다. 원하는 경우 기술을 동시에 사용할 수 있습니다. 사실상 주력 차량이 될 가능성이 크다. FSS 사용에 대한 것입니다(그러한 이유로 이 섹션에서는 FSS에 대해 더 이상 논의하지 않습니다). 간단히 말해서, TEF에서는 MAINCHAIN을 위해 설계되거나 개발된 원래 대상 계약 SC입니다. 하이브리드 계약으로 리팩토링됩니다. 이 리팩토링은 두 가지 상호 운용성을 생성합니다. 하이브리드 계약의 일부: 명확성을 위해 우리가 언급하는 MAINCHAIN 계약 SCa TEF의 맥락에서 앵커 계약 및 DON의 실행 파일 실행 파일입니다. 는 계약 SCa는 사용자의 자산을 관리하고 권위 있는 상태 전환을 실행하며 DON의 오류에 대비한 보호 레일(섹션 7.3 참조)을 제공합니다. 실행 파일 exec 트랜잭션을 순서대로 나열하고 관련 oracle 데이터를 제공합니다. 묶을 수 있다 다양한 방법(예: 유효성 증명 기반 또는 낙관적인 rollups, DON에 의한 기밀 실행 등 우리는 개발자가 계약을 쉽게 분할할 수 있는 도구를 개발할 것으로 기대합니다. 고급 언어로 작성된 SC는 MAINCHAIN 및 DON 로직, SCa 및 안전하고 효율적으로 구성되는 각각의 임원입니다. TEF를 사용하여 고성능 트랜잭션 체계를 고성능과 통합 oracles는 oracle 확장 접근 방식의 핵심입니다. 3.5 멤풀 서비스 지원을 위해 DON에 배포하려는 중요한 애플리케이션 계층 기능 FSS와 TEF는 Mempool Services(MS)입니다. MS는 어댑터로 볼 수도 있지만, 그러나 최고 수준의 지원을 제공합니다. MS는 레거시 호환 트랜잭션 처리를 지원합니다. 이 용도에서는 MS 대상 계약을 위해 의도된 트랜잭션을 메인 체인의 멤풀에서 수집합니다. 메인체인의 SC. 그런 다음 MS는 이러한 트랜잭션을 DON의 실행 파일에 전달합니다. 원하는 방식으로 처리되는 곳입니다. MS 데이터는 DON에서 사용할 수 있습니다. DON에서 SC로 직접 전달될 수 있는 트랜잭션을 작성하거나 SC를 호출하는 다른 계약으로. 예를 들어 DON은 트랜잭션을 전달할 수 있습니다. MS를 통해 수집하거나 MS 데이터를 사용하여 보내는 거래에 대한 가스 가격을 설정할 수 있습니다. 메인체인. MS는 mempool을 모니터링하기 때문에 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에 대해 출력하는 보고서(증명된 보고서라고 함): 증명된 보고서의 중앙값 보고서는 두 정직한 노드가 보고한 값과 같거나 그 사이에 있습니다. 이 속성은 OCR의 주요 안전 조건입니다. 리더는 중앙값에 어느 정도 영향을 미칠 수 있습니다. 입증된 보고서의 가치는 이 정확성 조건에만 적용됩니다. OCR은 다양한 방식으로 값을 집계하는 메시지 유형으로 확장됩니다. Chainlink 네트워크의 활성 및 정확성 목표는 오늘날 필요하지 않지만 OCR이 완전한 합의 프로토콜이 되려면 기존 BFT 프로토콜에는 없는 몇 가지 추가 기능 형태를 제공하기 위해 OCR이 필요합니다. 특히 다음과 같습니다. 1. 전부 아니면 전무의 오프체인 보고서 방송: OCR은 증명된 보고서를 보장합니다. 모든 정직한 노드가 신속하게 사용할 수 있게 되거나 그 중 누구도 사용할 수 없게 됩니다. 이것이 공정성이다 정직한 노드가 참여할 기회를 갖도록 보장하는 재산 증명된 보고서 전송 시. 2. 안정적인 전송: OCR은 결함이 있거나 악의적인 경우에도 보장합니다. 모든 OCR 보고서와 메시지가 특정 내에서 SC로 전송되는 노드, 미리 정의된 시간 간격. 이는 활성 속성입니다. 3. 계약 기반 신뢰 최소화: SC는 잠재적으로 잘못된 OCR 생성 보고서를 필터링합니다(예: 보고된 값이 다른 값과 크게 벗어나는 경우). 최근에 받은 것. 이는 추가 프로토콜 정확성 적용의 한 형태입니다. 이 세 가지 속성은 모두 DONs에서 자연스러운 역할을 합니다. 전부 아니면 전무 오프체인(DON) 방송은 암호화폐 경제 보장을 위한 중요한 구성 요소입니다. 안정적인 전송을 중심으로 이는 결국 필수적인 어댑터 속성입니다. 신뢰 SC의 최소화는 섹션 7.3에서 논의된 바와 같이 일종의 가드레일입니다. OCR은 또한 Chainlink의 oracle 네트워크에서 BFT 프로토콜의 운영 배포 및 개선을 위한 기반을 제공합니다. DONs의 기능.3.6.2 DECO와 타운 크라이어 DECO [234] 및 Town Crier [233]은 현재 진행 중인 관련 기술 쌍입니다. Chainlink 네트워크에서 개발되었습니다. 오늘날 대부분의 웹 서버에서는 사용자가 프로토콜을 사용하여 보안 채널을 통해 연결할 수 있습니다. TLS(전송 계층 보안) [94]이라고 합니다. (HTTPS는 HTTP의 변형을 나타냅니다. TLS를 사용하여 활성화됩니다. 즉, "https" 접두사가 붙은 URL은 보안을 위해 TLS를 사용함을 나타냅니다.) 하지만 대부분의 TLS 지원 서버에는 눈에 띄는 제한 사항이 있습니다. 즉, 디지털 서명을 하지 않습니다. 데이터. 결과적으로, 사용자나 증명자는 서버로부터 받은 데이터를 제시할 수 없습니다. 다음을 보장하는 방식으로 oracle 또는 smart contract와 같은 제3자 또는 검증자에게 데이터의 신뢰성. 서버가 데이터에 디지털 서명을 하더라도 기밀성 문제가 남아 있습니다. 증명자는 중요한 데이터를 제출하기 전에 수정하거나 수정하기를 원할 수 있습니다. 검증자. 그러나 디지털 서명은 수정된 데이터를 무효화하기 위해 특별히 설계되었습니다. 따라서 증명자가 기밀성을 유지하면서 변경하는 것을 방지합니다. 데이터에. (자세한 내용은 섹션 7.1을 참조하세요.) DECO와 Town Crier는 증명자가 웹에서 데이터를 얻을 수 있도록 설계되었습니다. 무결성과 기밀성을 보장하는 방식으로 검증자에게 제공합니다. 두 시스템은 다음에 의해 제공되는 데이터를 보장한다는 의미에서 무결성을 유지합니다. 검증자에 대한 증명자는 대상 서버에서 인증됩니다. 그들은 지원한다 증명자가 데이터를 수정하거나 수정할 수 있도록 허용한다는 의미의 기밀성(여전히 무결성 유지). 두 시스템의 주요 특징은 어떤 수정도 필요하지 않다는 것입니다. 대상 웹 서버. 기존 TLS 지원 서버와 함께 작동할 수 있습니다. 사실, 서버에 투명합니다. 서버의 관점에서 증명자는 일반적인 연결을 설정합니다. 두 시스템은 비슷한 목표를 가지고 있지만 지금 간략하게 설명하는 것처럼 신뢰 모델과 구현이 다릅니다. DECO는 무결성을 달성하기 위해 암호화 프로토콜을 기본적으로 사용합니다. 및 기밀성 속성. DECO를 사용하여 대상 서버와 세션을 설정하는 동안 Prover는 동시에 대화형 프로토콜에 참여합니다. 검증자. 이 프로토콜을 통해 증명자는 검증자에게 수신했음을 증명할 수 있습니다. 현재 세션 동안 서버에서 주어진 데이터 D 조각. 증명자는 할 수 있다 대안으로 검증자에게 D의 일부 속성에 대한 영지식 증명을 제시합니다. 따라서 D를 직접적으로 공개하지 않습니다. DECO의 일반적인 사용에서 사용자 또는 단일 노드는 개인 데이터베이스에서 데이터 D를 내보낼 수 있습니다. DON의 모든 노드에 대한 웹 서버와의 세션. 결과적으로 전체 DON은(는) D의 진위(또는 영지식 증명을 통해 D에서 파생된 사실)를 증명합니다. 이 문서의 뒷부분에 나오는 예제 애플리케이션 외에도 이 기능을 사용할 수 있습니다. DON을 통해 데이터 소스에 대한 높은 무결성 액세스를 증폭하는 데 사용됩니다. 노드가 1개만 있어도 예를 들어 다음과의 독점 계약으로 인해 데이터 소스에 직접 액세스할 수 있습니다. 데이터 제공자—전체 DON가해당 노드에서 내보내는 보고서입니다. Town Crier는 Intel과 같은 TEE(신뢰할 수 있는 실행 환경)를 사용합니다. SGX. 간단히 말해서, TEE는 애플리케이션을 실행하는 일종의 블랙박스 역할을 합니다. 변조 방지 및 기밀 방식. 원칙적으로 해당 호스트의 소유자라도 실행 중인 TEE는 TEE로 보호되는 애플리케이션을 (감지 불가능하게) 변경할 수 없으며, 비밀 데이터가 포함될 수 있는 애플리케이션 상태를 봅니다. Town Crier는 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 및 오늘날의 기타 분산형 시스템. 설명 된대로 추가 진화 이 백서에서는 이러한 기존 서비스에 추가 기능을 부여하고 도달하다. 세 가지 예는 다음과 같습니다. 데이터 피드: 오늘날 smart contract에 의존하는 대부분의 Chainlink 사용자는 데이터 피드 사용. 이는 주요 데이터의 현재 가치에 대한 보고서입니다. 신뢰할 수 있는 오프체인 소스에. 예를 들어 가격 피드는 가격을 보고하는 피드입니다. 자산(암호화폐, 원자재, 외환, 지수, 주식 등)에 따라 교환 또는 데이터 수집 서비스. 오늘날 이러한 피드는 이미 수십억 달러의 보안을 확보하는 데 도움이 됩니다. Aave [147]와 같은 DeFi 시스템에서의 사용을 통한 온체인 가치의 달러 신세틱스 [208]. Chainlink 데이터 피드의 다른 예로는 다음의 날씨 데이터가 있습니다. 매개변수적 작물 보험 [75] 및 선거 데이터 [93] 등이 있습니다. 이 백서에 설명된 DON 및 기타 기술의 배포는 다음을 포함하여 여러 가지 방법으로 Chainlink 네트워크의 데이터 피드 제공을 향상시킵니다. • 확장: OCR 이후 DON은 Chainlink 서비스 확장을 목표로 합니다. 그들이 지원하는 많은 blockchain에 걸쳐 극적으로. 예를 들어, 우리는 DONs는 다음을 사용하여 노드에서 제공하는 데이터 피드 수를 늘리는 데 도움이 됩니다. Chainlink 100년대부터 1000년대 그리고 그 이상까지. 이러한 확장은 Chainlink에 도움이 될 것입니다. 생태계는 smart contracts와 관련된 데이터를 포괄적으로 제공하고 기존 및 미래의 요구 사항을 충족하고 예상한다는 목표를 달성합니다.• 보안 강화: 중간 보고서를 저장하면 DONs에서 기록을 유지합니다. 충실도가 높은 모니터링과 성능 및 정확성 측정을 위한 노드 동작을 통해 평판 시스템에 대한 강력한 경험적 기반을 제공합니다. Chainlink 노드의 경우. FSS와 TEF를 통해 가격 피드를 통합할 수 있습니다. 프론트 런(front-running)과 같은 공격을 방지하는 유연한 방식으로 거래 데이터를 사용합니다. (명시적) staking은 보안의 기존 암호경제적 보호를 강화합니다. 데이터 피드의 • 피드 민첩성: blockchain-agnostic 시스템(실제로 더 광범위하게는 소비자 독립적 시스템)으로서 DONs는 다양한 사용자에게 데이터 피드 제공을 용이하게 할 수 있습니다. 의존 시스템의. 단일 DON는 주어진 피드를 동시에 세트로 푸시할 수 있습니다. 다양한 blockchain을 사용하여 체인별 oracle 네트워크가 필요하지 않으며 새로운 blockchain에 대한 기존 피드와 추가 피드를 빠르게 배포할 수 있습니다. 현재 서비스되는 blockchain에 대한 피드입니다. • 기밀성: DON에서 일반화된 계산을 수행하는 기능을 통해 민감한 데이터에 대한 계산이 온체인을 피하고 오프체인에서 수행될 수 있습니다. 노출. 추가적으로 DECO나 Town Crier를 사용하면 기밀성이 더욱 강화되어 공개되지 않은 데이터를 기반으로 보고서를 생성할 수 있습니다. DON 노드에도 노출됩니다. 예시는 섹션 4.3 및 섹션 4.5를 참조하세요. 검증 가능한 무작위 함수(VRF): 여러 유형의 DApp에는 자체 공정한 운영을 검증할 수 있도록 검증 가능한 올바른 무작위성 소스가 필요합니다. 대체 불가능한 토큰(NFTs)이 그 예입니다. Aavegotchi [23] 및 Axie Infinity [35]의 NFT 기능의 희귀성은 Chainlink VRF에 의해 결정되며 분포도 마찬가지입니다. Ether 카드 [102]의 티켓 기반 추첨을 통해 NFTs; 다양한 결과가 무작위로 결정되는 게임 DApp 비전통적인 금융 수단(예: PoolTogether [89]과 같은 무손실 저축 게임) 무작위 우승자. 기타 blockchain 및 blockchain이 아닌 애플리케이션에도 보안이 필요합니다. 분산 시스템 위원회의 선택과 복권 실행. hashes 블록은 예측할 수 없는 무작위성의 소스 역할을 할 수 있지만, 적대적인 채굴자(및 어느 정도 제출한 사용자)의 조작에 취약합니다. 거래). Chainlink VRF [78]은 훨씬 더 안전한 대안을 제공합니다. 안 oracle에는 개인 키가 오프체인으로 유지되고 공개 키 pk가 게시되는 연결된 개인/공개 키 쌍(sk, pk)이 있습니다. 임의의 값을 출력하려면 의존 계약에 의해 제공되는 예측할 수 없는 시드 x에 sk를 적용합니다(예: hash 블록) 및 DApp별 매개변수) 함수 F를 사용하여 y = Fsk(x)를 산출합니다. 정확성의 증거. (Chainlink에서 사용할 수 있는 VRF는 [180]을 참조하세요.) VRF 검증 가능은 pk에 대한 지식을 바탕으로 증명의 정확성, 즉 y의 정확성을 확인할 수 있다는 사실입니다. 결과적으로 y 값은 예측할 수 없습니다. x를 예측하거나 sk를 학습할 수 없고 서비스가 조작할 수 없는 적입니다.Chainlink VRF는 오프체인 개인 키의 관리와 관련된 애플리케이션 제품군 중 하나로 볼 수 있습니다. 보다 일반적으로 DONs는 보안을 제공할 수 있습니다. 애플리케이션 및/또는 사용자를 위한 개별 키의 분산형 저장 및 결합 일반화된 계산을 통해 이 기능을 사용할 수 있습니다. 그 결과 수많은 응용 프로그램이 탄생했습니다. 이 문서에서는 Proof of Key 관리를 포함하여 몇 가지 예를 제공합니다. 예비금(섹션 4.1 참조) 및 사용자의 분산 자격 증명(및 기타 디지털 자산)(섹션 4.3 참조). 키퍼: Chainlink 키퍼 [87]는 개발자가 분산형 코드를 작성할 수 있도록 해줍니다. 일반적으로 의존하는 smart contract의 실행을 트리거하기 위한 오프체인 작업 실행. Keeper가 등장하기 전에는 개발자가 이러한 오프체인을 운영하는 것이 일반적이었습니다. 논리 자체가 중앙 집중화된 실패 지점을 생성합니다(상당한 중복 개발 노력도 포함). 대신 Keeper는 사용하기 쉬운 프레임워크를 제공합니다. 이러한 작업을 분산 아웃소싱하여 개발 주기를 단축하고 활성 및 기타 보안 속성에 대한 강력한 보증. 키퍼는 무엇이든 지원할 수 있습니다 가격에 따른 대출 청산 또는 금융 거래 실행, 시간에 따른 에어드롭 또는 결제 시작 수확량 수확 등을 갖춘 시스템에서. DON 프레임워크에서 개시자는 여러 의미에서 Keeper의 일반화로 볼 수 있습니다. 개시자는 어댑터를 사용할 수 있으므로 온체인 및 오프체인 시스템에 대한 모듈화된 인터페이스 라이브러리를 통해 신속한 안전하고 정교한 기능 개발. 개시자는 다음에서 계산을 시작합니다. DONs의 완전한 다양성을 제공하는 실행 파일입니다. 온체인 및 오프체인 애플리케이션을 위해 이 백서에서 제시하는 다양한 분산형 서비스입니다. 3.6.4 노드 평판 / 성능 내역 기존 Chainlink 생태계는 기본적으로 다음의 성능 기록을 문서화합니다. 체인에 노드를 기여합니다. 이 기능을 통해 개인에 대한 성과 데이터를 수집, 필터링 및 시각화하는 평판 지향 리소스 모음이 탄생했습니다. 노드 운영자 및 데이터 피드. 사용자는 이러한 리소스를 참조하여 정보를 얻을 수 있습니다. 노드 선택에 대한 결정을 내리고 기존 네트워크의 작동을 모니터링합니다. 유사한 기능은 사용자가 DON을 선택하는 데 도움이 됩니다. 예를 들어 오늘날 market.link와 같은 무허가 마켓플레이스는 노드를 허용합니다. 운영자는 자신의 oracle 서비스를 나열하고 다음을 통해 오프체인 신원을 증명합니다. Chainlink에 있는 노드의 프로필을 해당 노드에 바인딩하는 Keybase [4]와 같은 서비스 소유자의 기존 도메인 이름 및 소셜 미디어 계정. 추가적으로 성능 market.link 및 Reputation.link에서 제공되는 것과 같은 분석 도구를 사용하면 사용자는 다음을 포함하여 개별 노드의 과거 성능에 대한 통계를 볼 수 있습니다. 평균 응답 대기 시간, 보고서 값과 합의 값의 편차 체인을 통해 중계되고, 수익이 창출되고, 작업이 완료되는 등의 일이 발생합니다. 이러한 분석 도구는 또한 사용자는 다른 사용자의 다양한 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ọ
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].
Decentralized가 구현하는 분산형 서비스
오라클 네트웍스 DON의 다양성과 이를 통해 다양한 새로운 서비스를 활성화하는 방법을 설명하기 위해, 이 섹션에서는 DON 기반 애플리케이션의 다섯 가지 예를 제시하고 이를 실현하는 하이브리드 계약: (1) 크로스체인 서비스의 한 형태인 보유량 증명; (2) 기업/레거시 시스템과의 인터페이스, 즉 미들웨어 기반의 구축 최소한의 비용으로 blockchain 애플리케이션 개발을 용이하게 하는 추상화 계층 blockchain-특정 코드 또는 전문 지식; (3) 분산형 ID, 사용자가 다음을 수행할 수 있는 도구 자신의 신분 증명서와 자격 증명을 획득하고 관리합니다. (4) 우선순위 채널, 중요한 인프라 트랜잭션을 적시에 포함하도록 보장하는 서비스(예: oracle 보고서) blockchain; (5) 기밀 유지 DeFi, 즉 금융 참여 당사자의 민감한 데이터를 숨기는 smart contracts. 여기서 우리는
SC를 사용하여 하이브리드 계약의 MAINCHAIN 부분을 나타내고 DON을 설명합니다. 구성 요소를 별도로 또는 실행 가능한 exec 측면에서 사용합니다. 4.1 예비금 증명 많은 애플리케이션의 경우 blockchain 사이에서 상태를 중계하는 것이 유용합니다. 에이 이러한 서비스의 인기 있는 응용 프로그램은 암호화폐 래핑입니다. 포장된 동전 등 WBTC [15]은 분산 금융(DeFi)에서 인기 있는 자산이 되고 있습니다. 그들은 소스 blockchain MAINCHAIN(1)에 "래핑된" 지원 자산을 예치하는 것이 포함됩니다. 다른 대상 blockchain MAINCHAIN(2)에 해당 token을 생성합니다. 예를 들어, 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가 작동하는 것이 가능합니다. 여러 관리인 중 한 명으로서, 심지어는 유일한 분산형 관리인으로서 래핑된 자산. DONs는 보안을 강화하는 플랫폼 역할을 할 수 있습니다. 보유금 증명을 사용하는 기존 서비스. 예를 들어 MAINCHAIN(1)이 Bitcoin이고 MAINCHAIN(2)이 Ethereum이라고 가정합니다. MAINCHAIN(2)에서 계약 SC는 래핑된 BTC를 나타내는 token을 발행합니다. DON BTC 주소 주소를 제어합니다(1) DON. BTC를 래핑하기 위해 사용자 U는 다음에서 X BTC를 보냅니다. 주소(1) 유 추가하기(1) DON MAINCHAIN(2)-주소 주소(2)와 함께 유. DON 모니터 주소(1) DON MAINCHAIN(1)에 대한 어댑터를 통해. U의 예금을 관찰하면 충분히 높은 확률로 확인된 후 어댑터를 통해 SC로 메시지를 보냅니다. 메인체인(2). 이 메시지는 SC에게 addr(2)에 대해 X tokens를 생성하도록 지시합니다. 유. U가 X tokens를 해제하려면 그 반대가 발생합니다. 그러나 MAINCHAIN(1)에서는 주소(1) DON는 X BTC를 addr(1)로 보냅니다. U(또는 사용자가 요청한 경우 다른 주소로). 물론 이러한 프로토콜은 직접적으로 작동하기보다는 교환과 함께 작동하도록 조정될 수 있습니다. 사용자와 함께. 4.2 엔터프라이즈/레거시 시스템과의 인터페이스 DON은 증명의 예에서와 같이 blockchain 사이에서 브리지 역할을 할 수 있습니다. 하지만 또 다른 목표는 예비군 사이의 양방향 다리 역할을 하는 것입니다. blockchains 및 레거시 시스템 [176] 또는 중앙 은행과 같은 blockchain 유사 시스템 디지털 통화 [30]. 기업은 기존 시스템과 시스템을 연결하는 데 있어 여러 가지 과제에 직면해 있습니다. 다음을 포함하는 분산형 시스템에 대한 프로세스:• 블록체인 민첩성: 블록체인 시스템은 빠르게 변화합니다. 기업은 blockchain의 급속한 새로운 등장이나 인기 상승에 직면할 수 있습니다. 상대방이 거래를 원하지만 기업이 이를 수행할 수 없는 경우 기존 인프라를 지원합니다. 일반적으로 blockchains의 역동성은 개별 기업이 전체 생태계를 따라가는 것은 어렵습니다. • 블록체인 관련 개발 리소스: 많은 조직의 경우, 특히 다음과 같은 관점에서 최첨단 blockchain 전문 지식을 고용하거나 육성하는 것이 어렵습니다. 민첩성에 도전합니다. • 개인 키 관리: blockchains 또는 암호화폐에 대한 개인 키를 관리하려면 기존 사이버 보안과 다른 운영 전문 지식이 필요합니다. 많은 기업에서는 사용할 수 없습니다. • 기밀성: 기업은 자신의 민감하고 독점적인 정보를 노출하는 것을 꺼립니다. 체인의 데이터. 이러한 어려움 중 처음 세 가지를 해결하기 위해 개발자는 DON를 사용하면 됩니다. 엔터프라이즈 시스템에서 읽거나 쓸 수 있도록 하는 보안 미들웨어 계층 blockchains. DON는 다음과 같은 자세한 기술적 고려 사항을 추상화할 수 있습니다. 개발자와 사용자 모두를 위한 가스 역학, 체인 재구성 등. 작성자: 엔터프라이즈 시스템에 간소화된 blockchain 인터페이스를 제공함으로써 DON은(는) 다음을 수행할 수 있습니다. blockchain 인식 엔터프라이즈 애플리케이션의 개발을 상당히 단순화하여 기업이 blockchain 특정 개발 리소스를 획득하거나 육성해야 하는 부담을 제거합니다. DONs의 이러한 사용은 엔터프라이즈 개발자가 다음을 수행할 수 있다는 점에서 특히 매력적입니다. 대체로 blockchain 불가지론적인 스마트 계약 애플리케이션을 만듭니다. 그 결과, DON이 미들웨어 역할을 하도록 계측된 blockchain 세트가 더 크면 기업 사용자가 쉽게 액세스할 수 있는 blockchain 세트가 더 커졌습니다. 개발자 최소한의 수정만으로 기존 blockchain의 애플리케이션을 새로운 애플리케이션으로 포팅할 수 있습니다. 내부적으로 개발된 애플리케이션에 적용됩니다. 추가적인 기밀성 문제를 해결하기 위해 개발자는 이 문서에서 소개하고 DON 애플리케이션을 지원하기 위해 배포할 예정인 도구입니다. 여기에는 DECO 및 Town Crier 섹션 3.6.2와 기밀 유지가 포함됩니다. 섹션 7.1.2에서 논의된 API 수정과 이 섹션의 나머지 부분에서 다루는 다양한 애플리케이션별 접근 방식. 이 DON 시스템은 다음을 제공할 수 있습니다. 공개하지 않고 엔터프라이즈 시스템 상태에 대한 높은 무결성, 온체인 증명 체인에 있는 민감한 기업 소스 데이터. 4.3 분산형 신원 분산형 ID는 사용자가 다음을 수행할 수 있어야 한다는 개념에 대한 일반적인 용어입니다. 제3자에게 의존하기보다는 자신의 자격 증명을 획득하고 관리합니다. 그래서. 분산형 자격 증명은 보유자의 속성이나 주장에 대한 증명입니다.흔히 클레임이라고 불리는 것입니다. 자격 증명은 엔터티에 의해 디지털 서명됩니다. 클레임을 사용자와 정식으로 연결할 수 있는 발급자입니다. 대부분의 제안된 계획에서는 클레임은 범용 식별자인 분산 식별자(DID)와 연결됩니다. 특정 사용자. 자격 증명은 사용자가 보유한 개인 키의 공개 키에 바인딩됩니다. 따라서 사용자는 개인 키를 사용하여 소유권 주장을 증명할 수 있습니다. 분산형 신원으로서의 비전은 기존 및 제안된 계획입니다(예: [14, 92, 129, 216]에는 세 가지 심각한 제한이 있습니다. • 레거시 호환성 부족: 기존 분산형 ID 시스템은 발급자라고 불리는 당국 커뮤니티가 DID 자격 증명을 생성합니다. 왜냐하면 기존 웹 서비스는 일반적으로 데이터에 디지털 서명을 하지 않으므로 발급자가 시작되어야 합니다. 특수 목적 시스템으로. 왜냐하면 아무런 인센티브도 없이는 이 일을 할 동기가 없기 때문입니다. 탈중앙화된 신원 생태계에서는 닭과 달걀의 문제가 발생합니다. 다른 곳에서는 즉, 발급자 생태계를 부트스트랩하는 방법이 불분명합니다. • 작동하지 않는 키 관리: 분산형 ID 시스템에서는 사용자가 다음을 수행해야 합니다. 개인 키 관리, 암호화폐 경험을 통해 알 수 있는 사실 실행 불가능한 부담이 되는 것입니다. 약 4,000,000 Bitcoin이(가) 발생한 것으로 추산됩니다. 키 관리 실패로 인해 영구적으로 손실되었으며 [194] 많은 사용자가 [193] 거래소의 암호화폐 자산으로 인해 분산화가 약화됩니다. • 개인 정보 보호 Sybil 저항 부족: 투표, token 판매 중 token의 공정한 할당 등과 같은 애플리케이션의 기본 보안 요구 사항은 다음과 같습니다. 사용자는 여러 ID를 주장할 수 없습니다. 기존의 분산형 신원 제안에서는 사용자가 이를 달성하기 위해 실제 신원을 공개해야 합니다. Sybil 저항으로 인해 중요한 개인 정보 보호 보장이 약화됩니다. 노드 위원회의 조합을 사용하여 이러한 문제를 해결하는 것이 가능합니다. DON 내에서 분산 계산을 수행하고 DECO와 같은 도구를 사용합니다. 또는 CanDID [160]이라는 시스템에 표시된 것처럼 Town Crier입니다. DECO 또는 Town Crier는 설계에 따라 수정 없이 기존 웹 서비스를 전환할 수 있습니다. 기밀 유지 자격 증명 발급자로 변경됩니다. DON을 사용하여 관련 항목을 내보낼 수 있습니다. 이러한 목적으로 데이터를 자격 증명으로 변환하고, 민감한 데이터를 숨겨서는 안 됩니다. 자격 증명에 나타납니다. 또한 사용자의 키 복구를 용이하게 하여 키 관리 문제를 해결합니다. 문제가 발생하면 DON을 사용하면 사용자가 개인 키를 비밀 공유 형식으로 저장할 수 있습니다. 사용자는 다음을 수행할 수 있습니다. DON의 노드에 증명하여 키를 복구합니다. 마찬가지로 Town Crier를 사용하거나 DECO—미리 결정된 웹 제공업체 집합의 계정에 로그인하는 기능(예: 트위터, 구글, 페이스북). Town Crier 또는 DECO를 사용하는 것의 이점은 다음과 같습니다. OAUTH는 사용자 개인정보 보호입니다. 이 두 도구를 사용하면 사용자가 DON에 공개되는 것을 피할 수 있습니다. 실제 신원을 파생할 수 있는 웹 제공자 식별자. 마지막으로 [160]에 표시된 것처럼 Sybil 저항을 제공하려면 DON이 다음을 수행할 수 있습니다. 사용자를 위한 고유한 실제 식별자의 개인 정보 보호 변환을 수행합니다. (예: 사회보장번호(SSN))를 사용자 등록 시 온체인 식별자로 변환합니다.이를 통해 시스템은 다음과 같은 민감한 데이터 없이 중복 등록을 감지할 수 있습니다. SSN은 개별 DON 노드에 공개됩니다.7 DON은 외부 분산 ID를 대신하여 이러한 서비스를 제공할 수 있습니다. 허가가 없거나 허가된 blockchain의 시스템(예: Hyperledger 인스턴스) 인디 [129]. 적용 예: KYC: 분산형 신원은 다음을 위한 수단으로 유망합니다. 사용자를 개선하는 동시에 blockchains의 금융 애플리케이션에 대한 요구 사항을 간소화합니다. 프라이버시. 해결하는 데 도움이 될 수 있는 두 가지 과제는 자금 세탁 방지/고객 파악(AML/KYC) 규정에 따른 인증 및 규정 준수 의무입니다. 많은 국가의 AML 규정에 따라 금융 기관(및 기타 기업)은 거래하는 개인 및 기업의 신원을 확인하고 확인해야 합니다. 그들은 거래를 수행합니다. KYC는 금융 기관의 한 구성 요소를 형성합니다. 일반적으로 사용자 행동을 모니터링하고 자금 흐름을 관찰하는 등 광범위한 AML 정책이 포함됩니다. KYC에는 일반적으로 사용자에게 어떤 형태로든 신원 자격 증명을 제시하는 과정이 포함됩니다(예: 사용자의 얼굴 앞에 신분증을 들고 온라인 웹 양식에 입력 비디오 세션 등). 분산형 자격 증명의 안전한 생성 및 제시 원칙적으로 다음과 같은 여러 측면에서 유익한 대안이 될 수 있습니다. (1) KYC 프로세스는 사용자와 금융 기관 모두에게 더 효율적입니다. 자격 증명을 취득하면 모든 금융 기관에 원활하게 제시될 수 있습니다. (2) 타협을 통한 신원 도용 기회를 줄여 사기를 줄입니다. 개인 식별 정보(PII) 및 영상 확인 중 스푸핑 그리고 (3) 사용자가 통제권을 유지함에 따라 금융 기관의 PII 손상 위험을 줄입니다. 자신의 데이터. AML 규정 준수 실패로 인해 금융 기관이 수십억 달러의 벌금을 지불하고 많은 금융 기관이 KYC에 매년 수백만 달러를 지출한다는 점을 고려하면 개선을 통해 금융 기관에 상당한 비용 절감 효과를 가져올 수 있습니다. 그리고 더 나아가 소비자를 위한 [196]. 전통적인 금융 부문은 부진하지만 새로운 규정 준수 도구를 채택하기 위해 DeFi 시스템에서는 이를 점점 더 많이 수용하고 있습니다 [43]. 적용 예: 과소담보 대출: 대부분의 DeFi 애플리케이션은 오늘날 지원 대출은 완전 담보 대출로만 이루어집니다. 대출을 받은 것들이에요 대출금을 초과하는 가치의 암호화폐 자산을 예치하는 차용자. 최근 DeFi 커뮤니티에서 일반적으로 과소담보 대출이라고 부르는 것에 대한 관심이 높아졌습니다. 이와 대조적으로 이는 해당 담보가 제공되는 대출입니다. 대출 원금보다 가치가 낮은 경우. 과소담보 대출 전통적인 금융 기관에서 흔히 제공하는 대출과 유사합니다. 의지하기보다는 대출 상환을 보장하기 위해 예치된 담보를 기반으로 대출을 제공합니다. 차용인의 신용 기록에 대한 결정. 7이 변환은 분산 의사 난수 함수(PRF)를 사용합니다.담보가 부족한 대출은 DeFi 대출 시장의 초기 단계이지만 성장하고 있는 부분을 구성합니다. 그들은 전통적인 금융 기관에서 사용하는 것과 같은 메커니즘에 의존합니다. 법적 계약과 같은 기관 [91]. 성장을 위한 필수 요구 사항 기존 대출 결정의 핵심 요소인 사용자 신용도에 대한 데이터를 강력한 무결성을 제공하는 방식으로 시스템에 제공할 수 있는 능력이 될 것입니다. 올바른 데이터 보장. DON 지원 분산형 신원 시스템을 통해 차용자가 될 수 있습니다. 보존하면서 신용도를 증명하는 높은 보증 자격 증명을 생성합니다. 민감한 정보의 기밀성. 특히 차용인은 다음을 생성할 수 있습니다. 신뢰할 수 있는 온라인 소스의 기록을 기반으로 한 자격 증명만 노출합니다. 잠재적으로 민감한 다른 데이터를 노출하지 않고 DON에 의해 증명된 데이터입니다. 에 대한 예를 들어, 차용인은 자신의 신용 점수를 나타내는 자격 증명을 생성할 수 있습니다. 일련의 신용 조사 기관이 자신을 공개하지 않고 특정 기준점(예: 750)을 초과합니다. 정확한 점수 또는 그녀의 기록에 있는 기타 데이터. 또한 원하는 경우 해당 자격 증명 익명으로 생성될 수 있습니다. 즉, 사용자 이름이 민감한 데이터로 취급될 수 있습니다. oracle 노드나 분산 자격 증명에 노출되지 않습니다. 자격 증명 애플리케이션에 따라 온체인 또는 오프체인으로 사용될 수 있습니다. 요약하자면, 차용인은 자신의 신용에 대해 대출 기관에 필수 정보를 제공할 수 있습니다. 강력하고 진실성이 있고 불필요하고 민감한 정보가 노출될 위험이 없는 역사 데이터. 차용인은 기타 다양한 기밀 유지 자격 증명을 제공할 수도 있습니다. 대출 결정에 도움이 됩니다. 예를 들어 자격 증명은 차용인의 다음 예에서 볼 수 있듯이 (오프체인) 자산을 소유합니다. 적용 예: 인증: 많은 관할권에서는 미등록 증권을 판매할 수 있는 투자자 등급을 제한합니다. 예를 들어 미국의 경우 SEC 규정 D는 그러한 투자 기회에 대해 인증을 받도록 규정하고 있습니다. 개인은 100만 달러의 순자산을 보유해야 하고, 특정 최소 소득 요건을 충족하거나 특정 전문 자격을 갖추어야 합니다[209, 210]. 현재 인증 프로세스가 번거롭고 비효율적이며 종종 증명서가 필요합니다. 회계사 또는 이와 유사한 증거. 분산형 신원 시스템을 통해 사용자는 다음에서 자격 증명을 생성할 수 있습니다. 인증 준수를 입증하는 기존 온라인 금융 서비스 계정 규정을 준수하여 보다 효율적이고 개인 정보를 보호하는 KYC 프로세스를 촉진합니다. 는 또한 DECO와 Town Crier의 개인 정보 보호 속성을 통해 다음이 가능해집니다. 사용자의 재정 상태에 대한 세부 정보를 직접 공개하지 않고 무결성을 강력하게 보장하여 자격 증명을 생성합니다. 예를 들어, 사용자는 자격 증명을 생성할 수 있습니다. 추가 정보를 공개하지 않고 그녀의 순자산이 최소 100만 달러임을 증명합니다. 그녀의 재정 상태에 대한 정보. 4.4 우선순위 채널 우선순위 채널은 DON을 사용하여 쉽게 구축할 수 있는 유용한 새 서비스입니다. 그들의
목표는 MAINCHAIN에서 적시에 선택되고 우선순위가 높은 거래를 제공하는 것입니다. 네트워크 정체 기간 동안. 우선순위 채널은 다음과 같은 형태로 볼 수 있습니다. 블록 공간에 대한 선물 계약 및 암호화폐 상품으로서 일부로 만들어진 용어입니다. 프로젝트 시카고 [61, 136]. 우선순위 채널은 특히 금융 거래와 같은 일반적인 사용자 수준 활동이 아닌 채굴자가 oracles, 계약에 대한 거버넌스 기능 등과 같은 인프라 서비스를 활성화할 수 있도록 고안되었습니다. 실제로 여기에서 설계된 대로 우선순위는 네트워크 내 채굴력의 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는 mempool을 모니터링하여 트랜잭션 배치 시 트리거됩니다. M이 채굴한 거래를 U가 제출하면 SC에 성공 메시지를 보냅니다. 시기적절한 방법과 서비스 장애 발생 시 장애 메시지를 제공합니다. SC는 성공 메시지를 받고 M에게 $p 지불금을 보내고 남은 자금을 모두 보냅니다. 실패 메시지를 받으면 $d를 포함하여 U로 보냅니다. 성공적으로 종료되면 M에게 예금 $d를 해제합니다. 채굴자 M은 물론 여러 사용자에게 우선순위 채널을 동시에 제공할 수 있습니다. 사용자는 미리 합의된 수의 메시지에 대해 U를 사용하여 우선순위 채널을 열 수 있습니다. 4.5 기밀 유지 DeFi / Mixicles 오늘날 DeFi 애플리케이션 [1]은 사용자에게 기밀성을 거의 또는 전혀 제공하지 않습니다. 모든 거래는 체인에서 볼 수 있습니다. 다양한 영지식 기반 접근 방식(예: [149, 217]), 거래 프라이버시를 제공할 수 있으며 TEF는 이를 지원할 만큼 충분히 일반적입니다. 하지만 이러한 접근 방식은 포괄적이지 않으며, 예를 들어 일반적으로 다음 사항을 숨기지 않습니다. 거래의 기반이 되는 자산. DONs에서 궁극적으로 지원하려는 광범위한 계산 도구 세트는 이러한 격차를 메울 수 있는 다양한 방법으로 개인 정보 보호를 활성화하여 다른 시스템의 개인 정보 보호 보장을 보완합니다. 예를 들어, Chainlink 연구소 연구원 [135]이 제안한 기밀 유지 DeFi 도구인 Mixicles는 금융 상품을 뒷받침하는 자산 유형이며 DON에 매우 자연스럽게 들어맞습니다. 프레임워크. Mixicle은 간단한 바이너리를 구현하는 용도로 가장 쉽게 설명됩니다. 옵션. 바이너리 옵션은 두 명의 사용자가 참여하는 금융 상품입니다. 플레이어로서 [135]과의 일관성을 위해 여기를 참조하십시오. 가능한 두 가지 이벤트에 베팅하세요. 결과(예: 자산이 미리 지정된 시간에 목표 가격을 초과하는지 여부) 다음 예에서는 아이디어를 보여줍니다. 예시 2. Alice와 Bob은 자산 가치를 기반으로 한 바이너리 옵션의 당사자입니다. 캐롤의 버블 토큰(CBT)이라고 합니다. Alice는 CBT의 시장 가격이 다음과 같을 것이라고 베팅했습니다. 2025년 6월 21일 정오 T 시간에 최소 250 USD; Bob은 그 반대로 베팅했습니다. 각 플레이어 미리 지정된 기한까지 100 ETH를 입금합니다. 승리하는 위치에 있는 플레이어 200 ETH를 받습니다(즉, 100 ETH를 얻습니다). 물론 8D는 M이 높은 확률을 준수할 수 있을 만큼 충분히 커야 합니다. 에 대한 예를 들어 M이 네트워크 마이닝 파워의 20%를 제어하는 경우 D = 100을 선택할 수 있습니다. 실패 확률은 2 × 10−10, 즉 10억분의 1 미만입니다.기존 Chainlink oracle 네트워크 O를 고려하면 스마트한 구현이 쉽습니다. 예시 2의 합의를 실현한 SC 계약. 두 플레이어가 각각 예치 SC에서는 100 ETH. T 이후에, 가격 r을 요청하는 쿼리 q가 O로 전송됩니다. T.O 시점의 CBT는 이 가격에 대한 보고서 r을 SC에 보냅니다. SC는 Alice에게 돈을 보냅니다. r ≥250이면 Bob이고, 그렇지 않으면 Bob입니다. 그러나 이 접근법은 체인상의 r을 드러냅니다. 관찰자가 바이너리 옵션의 기본 자산을 추론할 수 있도록 합니다. Mixicles라는 용어에서는 결과를 개념적으로 생각하는 것이 도움이 됩니다. 조건자로 계산된 이진 값을 전송하는 스위치 측면에서 SC의 스위치(r). 이 예에서는 r ≥250이면 switch(r) = 0입니다. 이 결과가 주어지면 Alice가 승리합니다. 그렇지 않으면 switch(r) = 1이고 Bob이 승리합니다. DON은 실행 파일을 실행하여 기본 Mixicle을 하이브리드 계약으로 실현할 수 있습니다. 스위치(r)를 계산하고 이를 SC에 체인으로 보고하는 exec입니다. 이 구조를 보여드리겠습니다 그림 11에서. 그림 11: 예제 2의 기본 Mixicle 다이어그램. r을 보고하고 바이너리 옵션의 기본 자산인 oracle은 이진 값 스위치(r)만 전환하여 SC를 계약합니다. 이를 쉽게 달성할 수 있도록 부록 C.3에 어댑터 ConfSwitch를 지정합니다. DON의 목표입니다. ConfSwitch의 기본 아이디어는 매우 간단합니다. 신고하는 대신 r 값, ConfSwitch는 바이너리 스위치 값 switch(r)만 보고합니다. SC는 가능하다 스위치(r)만 기반으로 정확한 결제를 하고 스위치(r) 자체는 올바르게 결제하도록 설계되었습니다. 기본 자산(이 예에서는 CBT)에 대한 정보를 공개하지 않습니다. 추가적으로, 공개 키인 pkaud로 암호화된 원장의 (q, r)에 암호문을 배치하여 감사자인 어댑터 ConfSwitch는 기밀성을 유지하는 감사 추적을 생성합니다. 여기서 설명하기 위해 단순화를 위해 선택한 기본 Mixicle은 우리 예에서는 바이너리 옵션 뒤에 자산과 베팅이 있습니다. 본격적인 Mixicle [135]은(는) 두 가지 형태의 기밀성을 제공합니다. (1) 어떤 사건이 관찰자에게 숨겨지나요? 플레이어는 (즉, q와 r)에 베팅할 뿐만 아니라 (2) 어느 플레이어가 베팅에서 승리했는지에도 베팅합니다. Mixicles는 MAINCHAIN에서 실행되므로 한 플레이어 중 한 명이 릴레이해야 합니다. DON에서 MAINCHAIN으로 전환(r)하거나 실행 가능한 exec를 생성할 수 있습니다.
ConfSwitch의 출력에서 트리거되고 다른 어댑터를 호출하여 스위치(r)를 메인체인. 세 번째로 미묘한 유형의 기밀성도 고려해 볼 가치가 있습니다. 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
đượ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가 네트워킹, 컴퓨팅 및 스토리지 기능을 활용하여 제공할 것으로 예상되는 중요한 서비스 중 하나는 FSS(Fair Sequencing Services)입니다. FSS는 단순히 DON 프레임워크 내에서 구현된 애플리케이션으로 볼 수 있지만, 우리는 이를 전 세계적으로 높은 수요가 있을 것으로 믿는 서비스로 강조합니다. blockchains이며 Chainlink 네트워크가 이를 적극적으로 지원할 것으로 기대합니다. 공용 blockchain 네트워크에서 실행되면 오늘날의 많은 DeFi 애플리케이션이 사용자가 자신의 이익을 위해 활용할 수 있는 정보를 공개합니다. 기존 시스템에 만연해 있는 일종의 내부 정보 유출 및 조작 기회 시장 [64, 155]. 대신 FSS는 공정한 DeFi 생태계를 향한 길을 열어줍니다. FSS 개발자가 시장 조작으로부터 보호되는 DeFi 계약을 구축하는 데 도움이 됩니다. 정보 유출로 인해 발생합니다. 아래에서 강조하는 문제를 고려하면 FSS는 레이어 2 서비스에 특히 매력적이며 그러한 서비스의 프레임워크 내에 적합합니다. 이에 대해서는 섹션 6에서 논의합니다. 과제: 기존 무허가 시스템에서는 트랜잭션이 전적으로 주문됩니다. 광부의 재량에 따라. 허가된 네트워크에서는 validator 노드가 같은 힘. 이는 대체로 인식되지 않는 임시 중앙 집중화의 한 형태입니다. 그렇지 않으면 분산 시스템. 채굴자는 거래를 (일시적으로) 검열할 수 있습니다. 자신의 이익을 [171]하거나 자신의 이익을 극대화하기 위해 순서를 변경합니다. 이를 광산 추출 가능 가치(MEV) [90]이라고 합니다. MEV라는 용어는 약간 기만적입니다. 채굴자가 포착할 수 있는 가치에만 적용: 일부 MEV는 일반 사용자가 포착할 수 있습니다. 그러나 채굴자는 일반 사용자보다 더 많은 권한을 갖기 때문에 MEV는 모든 개체가 적대적 재정렬을 통해 얻을 수 있는 가치의 상한선을 나타냅니다. 그리고 보완적인 거래 삽입. 채굴자가 단순히 거래를 주문하는 경우에도 수수료(가스)를 기준으로 조작 없이 사용자가 직접 가스 가격을 조작할 수 있습니다. 덜 정교한 거래에 비해 거래를 유리하게 만듭니다. Daianet al. [90] 봇(채굴자가 아님)이 가져오는 방식을 문서화하고 수량화합니다. 오늘날 DeFi 시스템 사용자에게 해를 끼치는 방식으로 가스 역학의 이점과 방법 MEV는 심지어 blockchain의 기본 합의 계층의 안정성을 위협합니다. 거래 주문 조작의 다른 예는 [50, 154]와 같이 정기적으로 나타납니다.rollups와 같은 새로운 트랜잭션 처리 방법은 매우 유망한 접근 방식입니다. 처리량이 많은 blockchains의 확장 문제. 그러나 그들은 다루지 않습니다 MEV의 문제. 대신 rollup을 생성하는 엔터티로 이동합니다. 그 smart contract의 운영자이든 (zk-)rollup을 제공하는 사용자이든 상관없이 엔터티 유효성 증명은 거래를 주문하고 삽입할 수 있는 권한을 갖습니다. 즉, rollups MEV를 REV: 롤업 추출 가능 값으로 교체합니다. MEV는 멤풀에 제출된 향후 거래에 영향을 미칩니다. 하지만 아직 체인에 커밋되지는 않았습니다. 그러한 거래에 관한 정보는 광범위하게 네트워크에서 사용 가능합니다. 채굴자, validators 및 일반 네트워크 참가자는 따라서 이 지식을 활용하고 종속 트랜잭션을 생성합니다. 또한, 채굴자와 validator은 자신이 수행하는 거래의 순서에 영향을 미칠 수 있습니다. 스스로를 이용하고 이를 자신들에게 유리하게 활용합니다. 합의에 따른 거래 주문에 대한 리더의 과도한 영향력 문제 프로토콜은 1990년대 이후 문헌에 알려져 있지만[71, 190] 만족스럽지 않습니다. 솔루션은 지금까지 실제로 실현되었습니다 [97]. 주된 이유는 제안된 솔루션이 적어도 아주 최근까지는 대중과 쉽게 통합될 수 없다는 것입니다. blockchains, 이후까지 비밀로 유지되는 거래 내용에 의존하기 때문입니다. 그들의 순서가 결정되었습니다. 공정한 시퀀싱 서비스(FSS) 개요: DONs는 트랜잭션 주문을 분산화하고 의존자가 지정한 정책에 따라 이를 구현하는 도구를 제공합니다. 계약 작성자, 이상적으로는 공정하고 유리한 행위자를 원하는 사람이 아닌 사람 거래 순서를 조작합니다. 이러한 도구는 집합적으로 FSS를 구성합니다. FSS에는 세 가지 구성 요소가 포함됩니다. 첫 번째는 거래 모니터링이다. FSS에서는 O의 oracle 노드는 MAINCHAIN의 mempool을 모니터링하고 (원하는 경우) 허용합니다. 전문 채널을 통한 오프체인 거래 제출. 두 번째는 거래 순서입니다. 의존 계약에 대한 O 주문 거래의 노드 해당 계약에 대해 정의된 정책에 따라. 세 번째는 거래 게시입니다. 트랜잭션이 주문된 후 O의 노드는 트랜잭션을 공동으로 보냅니다. 메인 체인. FSS의 잠재적 이점은 다음과 같습니다. • 주문 공정성: FSS에는 개발자가 거래를 보장하는 데 도움이 되는 도구가 포함되어 있습니다. 특정 계약에 대한 입력은 불공정하지 않은 방식으로 주문됩니다. 자원이 풍부하고 기술적으로 정통한 사용자에게 유리합니다. 주문 정책 이 목적으로 지정될 수 있습니다. • 정보 유출의 감소 또는 제거: 네트워크 참가자가 향후 거래에 대한 지식을 이용할 수 없도록 보장함으로써 FSS는 이를 완화하거나 제거할 수 있습니다. 이용 가능한 정보를 기반으로 하는 선행 실행과 같은 공격을 제거합니다. 트랜잭션이 커밋되기 전의 네트워크. 그러한 악용 방지 누출은 원래 보류에 의존하는 적대적 거래를 보장합니다. 원래 거래가 커밋되기 전에는 거래가 원장에 들어갈 수 없습니다.• 거래 비용 절감: 제출 속도에 대한 플레이어의 요구 사항 제거 smart contract에 대한 거래를 통해 FSS는 거래 처리 비용을 크게 줄일 수 있습니다. • 우선순위 지정: FSS는 중요한 거래에 자동으로 특별한 우선순위를 부여할 수 있습니다. 주문. 예를 들어 oracle에 대한 선행 공격을 방지하기 위해 보고서(예: [79]), FSS는 oracle 보고서를 거래 흐름에 삽입할 수 있습니다. 소급하여. DONs에서 FSS의 가장 중요한 목표는 DeFi 제작자가 공정한 실현을 실현할 수 있도록 권한을 부여하는 것입니다. 금융 시스템, 즉 특정 사용자(또는 채굴자)에게 이익을 주지 않는 시스템 속도, 내부 지식 또는 기술 수행 능력을 기준으로 다른 사람보다 우수합니다. 조작. 명확하고 일반적인 공정성 개념은 파악하기 어렵고 완벽한 공정성은 합리적인 감각은 달성할 수 없습니다. FSS는 개발자에게 강력한 기능을 제공하는 것을 목표로 합니다. DeFi에 대한 설계 목표를 달성하는 데 도움이 되는 정책을 시행할 수 있는 도구 세트입니다. FSS의 주요 목표는 공정한 시퀀싱 서비스 역할을 하는 것이지만 DON의 목표인 MAINCHAIN은 FSS가 원하는 것과 동일한 공정성 중 일부입니다. 보장은 또한 실행되는 (분산형) 프로토콜에도 적합할 수 있습니다. DON 파티. 따라서 FSS는 하위 집합이 제공하는 서비스로 더 광범위하게 볼 수 있습니다. DON 노드는 MAINCHAIN 사용자가 보낸 트랜잭션뿐만 아니라 공정한 순서를 지정합니다. 또한 다른 DON 노드 간에 공유되는 트랜잭션(즉, 메시지)도 있습니다. 이 섹션에서는 우리는 주로 MAINCHAIN 거래 순서를 정하는 목표에 중점을 둘 것입니다. 섹션 구성: 섹션 5.1에서는 FSS 설계에 동기를 부여하는 두 가지 상위 수준 애플리케이션, 즉 oracle 보고서의 전면 실행 방지 및 방지를 설명합니다. 사용자 트랜잭션의 선행 실행. 그런 다음 FSS 설계에 대한 자세한 내용을 제공합니다. 섹션 5.2에서. 섹션 5.3에서는 공정한 주문 보장 및 수단의 예를 설명합니다. 그것을 달성하기 위해. 마지막으로 섹션 5.4와 섹션 5.5에서는 네트워크 수준의 위협에 대해 논의합니다. 네트워크 플러딩과 Sybil에 대해 각각 이러한 정책과 이를 해결하는 수단 공격. 5.1 전면 실행 문제 FSS의 목표와 설계를 설명하기 위해 우리는 프론트러닝의 두 가지 일반적인 형태를 설명합니다. 공격과 기존 솔루션의 한계. 프론트 런닝은 클래스를 예시합니다. 트랜잭션 주문 공격: 우리가 다루지 않는 백런 및 샌드위치(프론트 러닝 및 백 런) [237]과 같은 관련 공격이 많이 있습니다. 여기에 있지만 FSS도 해결하는 데 도움이 됩니다. 5.1.1 Oracle 선두 실행 blockchain 애플리케이션에 오프체인 데이터를 제공하는 전통적인 역할에서 oracles 전방 공격의 자연스러운 표적이 됩니다.다양한 가격 피드를 제공하기 위해 oracle을 사용하는 일반적인 디자인 패턴을 고려하십시오. 온체인 거래소로: 주기적으로(매시간) oracle은 가격 데이터를 수집합니다. 다른 자산을 교환 계약으로 보냅니다. 이러한 가격 데이터 거래 명백한 차익 거래 기회 제공: 예를 들어 최신 oracle 보고서에 일부 자산의 가격이 훨씬 높을 경우, 적이 oracle 보고서를 미리 실행할 수 있습니다. 자산을 매입하고 oracle의 신고가 처리되면 즉시 재판매하세요. 과속방지턱 및 소급 가격: oracle 선점 문제에 대한 자연스러운 해결책은 oracle 보고서에 다른 거래보다 특별한 우선순위를 부여하는 것입니다. 에 대한 예를 들어, oracle 보고서는 채굴자가 처리하도록 장려하기 위해 높은 수수료로 전송될 수 있습니다. 먼저 그들. 그러나 차익거래 기회가 높다면 선행매매를 막을 수는 없습니다. 또한 채굴자 자신의 차익 거래를 막을 수도 없습니다. 따라서 일부 거래소는 처리하기 전에 여러 블록에 대해 사용자 트랜잭션을 대기열에 넣는 등 보다 무거운 "속도 향상"을 구현하는 데 의존했습니다. 또는 새로운 oracle 보고서가 도착하면 가격을 소급하여 조정합니다. 이러한 솔루션의 단점은 교환 구현에 복잡성을 추가한다는 것입니다. 저장 요구 사항이 증가하여 거래 비용이 증가하고 자산 교환이 상당한 기간이 지난 후에만 확인되므로 사용자 경험이 중단됩니다. 편승: FSS로 넘어가기 전에 우리는 매우 간단하고 간단한 피기백(piggybacking)에 대해 논의합니다. oracle 전면 실행 문제에 대한 우아한 솔루션입니다. 주소에는 해당되지 않습니다. 그러나 다른 시나리오에서는 선행 실행됩니다. 즉, 온체인 컨트랙트에 정기적으로 보고서를 보내는 대신 oracles 사용자가 구매 또는 판매 시 거래에 추가하는 서명된 보고서를 게시합니다. 온체인 자산. 그런 다음 거래소는 보고서가 유효하고 최신인지 확인합니다. (예: oracle은 보고서가 유효한 블록 범위에 서명할 수 있음) 그것으로부터 관련 가격 피드. 이 간단한 접근 방식은 위의 "과속 방지턱"에 비해 여러 가지 장점이 있습니다. 접근 방식: (1) 교환 계약은 가격 피드 상태를 유지할 필요가 없습니다. 거래 비용이 낮아집니다. (2) oracle 보고서는 필요에 따라 체인에 게시되므로 oracle은 더 자주(예: 매분) 업데이트를 생성할 수 있습니다. 보고서 선행 실행으로 인한 차익거래 기회 최소화9; (3) 거래는 다음과 같습니다. 항상 새로운 가격 피드가 포함되어 있으므로 즉시 검증됩니다. 그러나 접근 방식이 완벽하지는 않습니다. 첫째, 이 피기백 솔루션은 거래소 사용자는 최신 oracle 보고서를 가져와서 첨부할 책임이 있습니다. 거래. 둘째, 편승은 차익거래 기회를 최소화하지만, 온체인 계약의 활성 상태에 영향을 주지 않고 이를 완전히 방지합니다. 실제로 만약에 oracle 보고서는 일부 블록 번호 n까지 유효하며 이후 거래가 블록에 제출됩니다. n + 1에는 새로운 유효한 보고서가 필요합니다. 본질적인 전파 지연으로 인해 oracles에서 사용자에게 보고하는 경우 블록 n + 1에 유효한 새 보고서는 9차익거래는 자산 가격의 활용 가능한 차이가 외부 차익을 초과하는 경우에만 가치가 있습니다. 자산을 사고 파는 데 필요한 수수료(예: 채굴자와 거래소가 수집한 자산)블록 n + 1이 채굴되기 전 일정 기간(예: 블록 n −k)에 공개됩니다. 단기 차익거래 기회가 존재하는 일련의 k개 블록을 생성합니다. 우리 이제 FSS가 이러한 제한 사항을 어떻게 해결하는지 설명합니다. FSS를 통해 oracle 보고서의 우선순위 지정: FSS는 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을 통해 tx1을 앞지르게 할 수 있습니다. tx2를 소유하고 tx1을 생성한 무고한 사용자를 속이세요. 예를 들어, 사용자는 정기적으로 특정 자산을 거래하는 것으로 알려져 있습니다. 그러한 공격을 예방하려면 다음이 필요합니다. 메타데이터 유출도 방지하는 완화 [62]. 이 문제에 대한 몇 가지 해결책 존재하지만 지연과 유용성 문제가 발생합니다. FSS를 사용하여 네트워크 순서에서 최종 순서까지: 선두주자의 기회 기존 시스템에는 순서를 보장하는 메커니즘이 없기 때문에 발생합니다. 거래는 사건의 순서와 정보 흐름을 존중하여 체인에 나타납니다. 네트워크 외부. 이는 blockchain에서 애플리케이션(예: 거래 플랫폼) 구현의 결함으로 인해 발생하는 문제를 나타냅니다. 이상적으로는 트랜잭션이 blockchain에서 동일한 순서로 커밋되었는지 확인하세요. 생성되어 blockchain의 P2P 네트워크로 전송됩니다. 하지만 blockchain 네트워크 이후
분산되어 있으면 그러한 주문을 캡처할 수 없습니다. 따라서 FSS는 메커니즘을 도입합니다. 분배로 인해 발생하는 공정성 위반으로부터 보호하기 위해 blockchain 네트워크의 성격. 5.2 FSS 세부정보 그림 12: 두 가지 다른 트랜잭션 경로를 갖춘 주문 공정 멤풀: 직접적이고 멤풀 기반. 그림 12는 FSS의 일반적인 개략도를 보여줍니다. 공정성을 보장하기 위해 FSS를 제공하는 DON은 MAINCHAIN에 진입할 때 거래 흐름을 방해해야 합니다. 클라이언트, MAINCHAIN의 smart contracts 또는 둘 다에 대한 조정이 필요할 수 있습니다. 높은 수준에서 FSS의 거래 처리는 세 가지로 분해될 수 있습니다. 아래에 설명된 단계: (1) 거래 모니터링; (2) 거래 순서; 그리고 (3) 거래 게시. 트랜잭션 순서 지정에 사용되는 주문 방법에 따라 다음 섹션에 설명된 대로 추가 프로토콜 단계가 필요합니다. 5.2.1 거래 처리 거래 모니터링: 우리는 FSS가 모니터링할 수 있는 두 가지 접근 방식을 구상합니다. 특정 smart contract을 대상으로 하는 사용자 트랜잭션, 직접 및 mempool 기반: • 직접: 직접 접근 방식은 개념적으로 가장 간단하지만 다음 사항에 대한 변경이 필요합니다. 트랜잭션이 분산형 Oracle로 직접 전송되도록 사용자 클라이언트메인 체인의 노드가 아닌 네트워크 노드. DON는 수집합니다 특정 smart contract SC로 향하는 사용자 트랜잭션을 기반으로 주문합니다. 일부 주문 정책에 대해 그런 다음 DON은 주문된 트랜잭션을 다음으로 보냅니다. smart contract 메인 체인에 있습니다. 일부 주문 메커니즘에는 트랜잭션을 생성하는 사용자가 암호화 방식을 사용해야 하므로 직접적인 접근 방식도 필요합니다. FSS로 보내기 전에 보호하십시오. • Mempool 기반: FSS와 레거시 클라이언트의 통합을 용이하게 하기 위해 DON Mempool Services(MS)를 사용하여 메인 체인의 mempool을 모니터링하고 수집할 수 있습니다. 거래. 직접 전송은 많은 계약에서 선호되는 구현일 가능성이 높습니다. 그리고 우리는 이것이 많은 경우 상당히 실용적일 것이라고 믿습니다. 우리는 기존 DApp을 최소한으로 수정하여 지원하는 방법에 대해 간략하게 논의합니다. 좋은 사용자 경험을 유지하면서 직접 전송합니다. 우리는 접근 방식을 설명합니다 오늘날 가장 인기 있는 선택이기 때문에 Ethereum 및 MetaMask [6]을 사용하지만 언급된 기술은 다른 체인과 지갑으로 확장되어야 합니다. 최근 Ethereum 개선 제안, “EIP-3085: 지갑 추가 Ethereum 체인 RPC 방법” [100], 사용자 정의 Ethereum 체인을 쉽게 타겟팅할 수 있습니다(다른 체인 ID 사용). MetaMask 및 기타 브라우저 기반 지갑의 재생 공격을 방지하기 위한 MAINCHAIN의 것입니다. 이 제안을 구현한 후 DON를 사용하려는 DApp은 직접 전송할 수 있도록 프런트 엔드에 단일 메서드 호출을 추가하기만 하면 됩니다. Ethereum 호환 API를 노출하는 DON에 대한 트랜잭션입니다. 그동안, "EIP-712: Ethereum 유형화된 구조화된 데이터 hash생성 및 서명" [49]은 약간의 정보를 제공합니다. DApp 사용자가 사용할 수 있는 더 복잡하지만 이미 널리 배포된 대안 DON 트랜잭션을 지정하는 구조화된 데이터에 서명하는 MetaMask입니다. DApp은 보낼 수 있습니다 이 서명된 구조화된 데이터를 DON에 보냅니다. 마지막으로 하이브리드 접근 방식도 가능하다는 점에 주목합니다. 예를 들어, 유산 클라이언트는 계속해서 메인 체인의 멤풀로 트랜잭션을 보낼 수 있지만 매우 중요합니다. 거래(예: oracle 보고서)는 DON 노드로 직접 전송됩니다(특히 가격 피드 업데이트와 같은 oracle 보고서를 제공하는 노드 세트 및 노드 세트 FSS 제공은 중복되거나 동일할 수 있습니다). 거래 순서: FSS의 주요 목적은 사용자 트랜잭션이 미리 정의된 정책에 따라 정렬되도록 보장하는 것입니다. 이 정책의 성격은 다음과 같습니다. 애플리케이션의 요구와 불공정 거래 명령 유형에 따라 다릅니다. 예방하는 것을 목표로 합니다. DON의 FSS는 데이터를 처리하고 로컬 상태를 유지할 수 있으므로, 그들은 정보를 기반으로 임의의 순서 지정 정책을 부과할 수 있습니다. oracles에서 사용 가능합니다. 특정 주문 정책과 그 구현은 이후 섹션 5.3에서 논의됩니다.거래 전기: 사용자로부터 직접 받거나 멤풀에서 수집한 사용자 트랜잭션을 수집하고 주문한 후 DON은 이러한 트랜잭션을 메인 체인으로 보냅니다. 따라서 DON의 메인 체인과의 상호 작용은 그대로 유지됩니다. 메인 체인의 채굴자가 관리하는 (잠재적으로 불공평한) 거래 명령이 적용됩니다. 분산형 거래 주문의 이점을 활용하기 위해 대상 스마트 따라서 계약 SC는 DON을 "일류" 시민으로 취급하도록 설계되어야 합니다. 우리 두 가지 접근 방식을 구별합니다. • DON 전용 계약: 가장 간단한 설계 옵션은 메인 체인을 스마트하게 만드는 것입니다. 계약 SC는 DON에 의해 처리된 거래만 수락합니다. 이 smart contract이(가) 제안한 순서대로 트랜잭션을 처리하는지 확인합니다. DON이지만 사실상 smart contract은 위원회 기반 시스템에서 운영되도록 제한됩니다(즉, DON 위원회는 이제 거래 주문 및 포함). • 이중 클래스 계약: 선호되고 보다 세분화된 설계를 통해 메인 체인이 스마트해집니다. 계약 SC는 DON 및 레거시에서 발생하는 트랜잭션을 수락합니다. 사용자10 그러나 DON에 의해 처리되지 않은 거래에는 전통적인 "과속 방지턱"이 적용됩니다. 예를 들어 DON의 거래가 처리될 수 있습니다. 즉시, 레거시 트랜잭션은 smart contract에 의해 "버퍼링"됩니다. 정해진 기간. 선행 실행을 방지하기 위한 기타 표준 메커니즘 커밋-공개 방식이나 VDF [53]과 같은 방식은 레거시에도 적용될 수 있습니다. 거래. 이렇게 하면 DON 주문된 트랜잭션이 처리됩니다. DON에 원치 않는 검열 권한을 부여하지 않고 합의된 명령 거래. FSS의 거래 순서 지정을 위해서는 거래가 "오프체인"으로 집계되어야 하므로 이 솔루션은 자연스럽게 온체인 처리 비용을 줄이기 위한 다른 집계 기술과 결합됩니다. 예를 들어, 수집한 후 거래를 주문하면 DON은 이러한 거래를 메인 체인에 보낼 수 있습니다. 단일 "일괄 트랜잭션"(예: rollup)으로 인해 총 트랜잭션이 줄어듭니다. 수수료. 거래 명령 집행: DON 전용 디자인이든 듀얼 클래스 디자인이든, 메인 체인 smart contract SC와 DON은 DON의 거래 순서가 유지되도록 보장하기 위해 공동 설계되어야 합니다. 여기서도 우리는 다른 것을 상상합니다. 디자인 옵션: • 시퀀스 번호: DON은 각 트랜잭션에 시퀀스 번호를 추가하고 이러한 트랜잭션을 메인 체인의 멤풀로 보낼 수 있습니다. 주요 10DON의 트랜잭션 모니터링이 멤풀을 기반으로 하는 경우 레거시 트랜잭션은 DON 트랜잭션과 구별되어야 DON에 의해 수집되지 않습니다(예: 특수 태그를 통해). 거래에 포함되거나 특정 가스 가격을 지정함으로써 가능합니다. DON 거래에 가스가 있습니다 특정 기준점 이하의 가격.체인 smart contract SC는 "순서가 맞지 않게" 도착하는 트랜잭션을 무시합니다. 우리 이 설정에서 메인 체인 채굴자는 DON을 무시하기로 결정할 수 있습니다. 트랜잭션 주문으로 인해 트랜잭션이 실패하게 됩니다. SC가 올바른 트랜잭션 순서를 강제하도록 (비싼) 상태를 유지함으로써 어느 정도 가능합니다. TCP가 누락된 패킷이 발견될 때까지 순서가 잘못된 패킷을 버퍼링하는 방법과 유사합니다. 받았습니다. • 거래 nonces: 많은 blockchains, 특히 Ethereum의 경우 위의 일련 번호 지정 방식은 내장된 트랜잭션 nonce을 활용하여 다음을 수행할 수 있습니다. 메인 체인 smart contract SC가 트랜잭션을 순서대로 처리하도록 강제합니다. 여기서 DON 노드는 DON 노드 간에 공유되는 키로 보호되는 단일 메인체인 계정을 통해 메인체인에 트랜잭션을 보냅니다. 계정의 transaction nonce은 거래가 올바른 순서로 채굴되고 처리되도록 보장합니다. • 집계 트랜잭션: DON은 rollup에서 여러 트랜잭션을 집계할 수 있습니다. (또는 rollup과 유사한 번들). 메인 체인 smart contract은 다음과 같아야 합니다. 이러한 집계 트랜잭션을 처리하도록 설계되었습니다. • 메인 체인 프록시를 사용한 집계 트랜잭션: 여기서 DON은 마찬가지로 트랜잭션을 메인 체인에 대한 하나의 "메타 트랜잭션"으로 묶지만 사용자 정의 프록시 smart contract를 사용하여 트랜잭션의 압축을 풀고 이를 대상 계약 SC. 이 기술은 레거시 호환성에 유용할 수 있습니다. 메타트랜잭션은 rollup과 유사하게 작동하지만 압축되지 않은 트랜잭션으로 구성된다는 점에서 다릅니다. 메인 체인에 한 번 게시된 거래 목록입니다. 마지막 디자인은 사용자 트랜잭션을 원활하게 지원한다는 장점이 있습니다. DON의 목표에 도달하기 전에 메인 체인 계약을 통해 스스로 프록시됩니다. SC와 계약을 맺다 예를 들어, 어떤 지갑에 거래를 보내는 사용자를 생각해 보세요. 계약은 내부 트랜잭션을 SC로 보냅니다. 시퀀스 할당 사용자의 지갑 계약이 그렇지 않은 경우를 제외하고 그러한 거래에 대한 번호는 까다로울 수 있습니다. 모든 내부 트랜잭션과 함께 시퀀스 번호를 전달하도록 특별히 설계되었습니다. SC. 마찬가지로 이러한 내부 트랜잭션은 SC로 직접 전송되는 메타트랜잭션으로 쉽게 집계될 수 없습니다. 우리는 다음에 대한 추가 설계 고려 사항에 대해 논의합니다. 아래의 프록시 거래. 5.2.2 트랜잭션 원자성 지금까지의 논의에서는 트랜잭션이 단일 개체와 상호작용한다고 암묵적으로 가정했습니다. 온체인 smart contract(예: 사용자가 교환소에 구매 요청을 보냅니다). 그러나 에서는 Ethereum와 같은 시스템에서 단일 트랜잭션은 여러 내부 트랜잭션으로 구성될 수 있습니다. 예를 들어 하나의 smart contract은 다른 계약의 함수를 호출합니다. 아래에서 우리는 "다중 계약" 거래 순서를 지정하기 위한 두 가지 고급 전략을 설명합니다. 트랜잭션의 원자성(즉, 다음에 의해 규정된 일련의 작업)을 보존합니다. 트랜잭션은 모두 올바른 순서로 실행되거나 전혀 실행되지 않습니다.강력한 원자성: 가장 간단한 해결책은 위에서 설명한 대로 FSS를 전체 "다중 계약" 거래에 직접 적용하는 것입니다. 즉, 사용자는 거래를 보냅니다. 네트워크에 들어가고 FSS는 이러한 거래를 모니터링하고 순서를 정하고 게시합니다. 메인 체인. 이 접근 방식은 기술적으로 간단하지만 한 가지 잠재적인 제한 사항이 있습니다. 거래는 공정한 활용을 원하는 두 계약 SC1 및 SC2와 상호 작용합니다. 시퀀싱 서비스를 사용하려면 이 두 계약의 시퀀싱 정책이 일관되어야 합니다. 즉, 각각 상호작용하는 두 개의 서로 다른 트랜잭션 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는 전송된 다른 트랜잭션과 관련하여 주문되어야 합니다. SC로 이동하되 ~txpre 및 ~txpost에 대한 시퀀스 순서는 열어 둡니다. Ethereum과 같은 시스템에서 트랜잭션 처리의 본질적인 특성을 고려할 때 특정 내부 트랜잭션을 대상으로 하는 시퀀싱 서비스를 개발하는 것은 간단하지 않습니다. 특별히 설계된 계약 SC를 사용하면 다음과 같이 실현할 수 있습니다. 1. 트랜잭션 tx가 네트워크로 전송되어 채굴됩니다(시퀀싱 없이). FSS에서 수행). 초기 ~txpre가 실행되고 ~txSC를 호출합니다. 2. SC는 ~txSC를 실행하지 않고 반환됩니다. 3. FSS는 SC에 대한 내부 거래를 모니터링하고 순서를 정한 후 다시 게시합니다. SC로(즉, 트랜잭션 ~txSC를 SC로 직접 보냄) 4. SC는 FSS로부터 받은 트랜잭션 ~txSC를 처리하고, ~txSC의 결과인 내부 트랜잭션 ~txpost를 발행합니다. 이 접근 방식을 사용하면 트랜잭션이 완전히 원자적으로 실행되지 않습니다(즉, 원본 트랜잭션 tx는 여러 개의 온체인 트랜잭션으로 분할되지만 순서는 내부 거래는 보존됩니다. 이 솔루션에는 여러 가지 설계 제약이 따릅니다. 예를 들어 ~txpre는 다음을 수행할 수 없습니다. ~txSC 및 ~txpost가 실행될 것이라고 가정합니다. 더욱이 SC는 다음과 같이 설계되어야 한다. 특정 사용자를 대신하여 ~txSC 및 ~txpost 트랜잭션을 실행합니다.FSS에서 보냈습니다. 이러한 이유로 보다 세분화된 "Strong Atomicity" 솔루션 실제로는 위의 내용이 바람직할 수 있습니다. 여러 트랜잭션과 관련된 보다 복잡한 종속성을 존중하기 위해 각각의 내부 거래에는 FSS의 거래 스케줄러가 포함될 수 있습니다. 관계형 트랜잭션 관리자에서 볼 수 있는 것과 유사한 정교한 기능 데이터베이스 관리자. 5.3 공정한 거래 순서 여기에서는 FSS에 의해 실현될 수 있는 거래 순서 결정 및 해당 구현에 대한 두 가지 공정성 개념에 대해 논의합니다. 정책 기반 주문 공정성 FSS에 의해 부과되며 인과관계 보존을 보장하므로 FSS에 추가적인 암호화 방법이 필요합니다. 주문 공정성: 질서 공정성은 합의 프로토콜에서 시간적 공정성에 대한 개념입니다. Kelkar et al.에 의해 처음으로 공식적으로 소개되었습니다. [144]. Kelkaret al. 거래가 이루어지는 자연정책의 형태를 달성하는 것을 목표로 합니다. DON(또는 P2P 네트워크, mempool 기반 FSS의 경우). 그러나 분산형 시스템에서는 다릅니다. 노드는 트랜잭션이 다른 순서로 도착하는 것을 볼 수 있습니다. 전체 주문 설정 모든 거래에 대한 문제는 기반이 되는 합의 프로토콜에 의해 해결되는 바로 그 문제입니다. 메인체인. Kelkaret al. [144] 따라서 다음과 같은 약한 개념을 도입합니다. 이는 "블록 주문 공정성"이라고 불리는 분산형 Oracle 네트워크의 도움으로 달성됩니다. DON이(가) 일정 시간 간격 동안 수신한 트랜잭션을 다음과 같이 그룹화합니다. 블록을 생성하고 해당 블록의 모든 트랜잭션을 동시에 동일한 위치에 삽입합니다. (즉, 높이)를 MAINCHAIN에 넣습니다. 따라서 이들은 함께 주문되며 실행 가능해야 합니다. 동시에, 그들 사이에 어떤 갈등도 일으키지 않습니다. 대략적으로 말하자면, 주문 공정성은 많은 노드가 τ2 이전에 트랜잭션 τ1을 본다면 다음과 같이 말합니다. τ1은 τ2 이전 또는 동일한 블록에서 시퀀스됩니다. 이런 거친 짓을 해서 거래 주문을 세분화하면 선행 실행 및 기타 주문 관련 공격 기회가 크게 줄어듭니다. Kelkaret al. Aequitas [144]라는 프로토콜 제품군을 제안합니다. 동기식, 부분 동기식, 비동기식 네트워크 설정을 포함한 다양한 배포 모델. Aequitas 프로토콜은 기본 BFT 합의에 비해 상당한 통신 오버헤드를 부과하므로 실제 사용에는 적합하지 않습니다. 그러나 우리는 사용할 수 있는 Aequitas의 실용적인 변형이 나타날 것이라고 믿습니다. FSS 및 기타 애플리케이션의 트랜잭션 순서 지정을 위한 것입니다. 일부 관련 계획에는 형식주의와 속성이 덜 수반되는 방식이 이미 제안되었습니다. 예를 들어 [36, 151, 236]이지만 실제 성능이 더 좋습니다. 이러한 구성표가 지원될 수 있습니다. FSS에서도요. "공정성"이라는 용어가 blockchain의 다른 곳에 나타난다는 점도 주목할 가치가 있습니다. 다른 의미를 지닌 문학, 즉 기회라는 의미에서의 공정성헌신된 자원 [106, 181] 또는 validators에 비례하는 광부 평등한 기회 [153]. 안전한 인과관계 보존: 분산 플랫폼에서 선행 실행 및 기타 주문 위반을 방지하는 가장 널리 알려진 접근 방식은 암호화에 의존합니다. 기술. 그들의 일반적인 특징은 거래 데이터 자체를 숨기고 합의 계층의 순서가 확립되었으며 거래 데이터를 공개합니다. 나중에 처리를 위해. 이는 거래 간의 인과적 순서를 보존합니다. blockchain에 의해 실행됩니다. 관련 보안 개념 및 암호화 프로토콜 blockchains [71, 190]이 출현하기 전에 상당히 개발되었습니다. "입력 인과성" [190] 및 "안전한 인과성 보존"[71, 97]의 보안 조건은 거래에 대한 정보가 알려지지 않도록 공식적으로 요구합니다. 글로벌 순서에서 이 거래의 위치가 결정되기 전에. 공격자는 그때까지 암호화된 방식으로 어떤 정보도 추론할 수 없어야 합니다. 강한 감각. 인과관계를 보존하기 위해 네 가지 암호화 기술을 구별할 수 있습니다. • 커밋-공개 프로토콜 [29, 142, 145]: 트랜잭션이 발표되는 대신 명확하게는 거래에 대한 암호화된 약속만 공개됩니다. 모든 커밋되었지만 숨겨진 트랜잭션이 주문된 후(blockchain 초기에) MAINCHAIN 자체의 시스템(여기서는 FSS에 의한 시스템)에서 보낸 사람은 미리 결정된 시간 간격 내에 약속을 열고 거래 데이터를 공개해야 합니다. 그런 다음 네트워크는 개시가 이전 약속을 충족하는지 확인합니다. 는 이 방법의 기원은 blockchains 출현 이전입니다. 비록 매우 간단하지만 이 접근 방식은 상당한 단점을 가져오고 두 가지 이유로 사용하기 쉽지 않습니다. 첫째, 주문 프로토콜 수준에서는 커밋만 존재하므로 트랜잭션의 의미는 다음과 같습니다. 합의 중에는 검증할 수 없습니다. 클라이언트까지의 추가 왕복 필요합니다. 그러나 더 심각한 것은 개봉이 불가능할 가능성에 무게를 두고 있습니다. 이는 서비스 거부 공격에 해당할 수 있습니다. 게다가, 그것은 일관되고 분산된 방식으로 오프닝이 유효한지 여부를 결정하는 것은 어렵습니다. 왜냐하면 모든 참가자는 오프닝이 도착했는지 여부에 동의해야 하기 때문입니다. 시간. • 지연된 복구가 포함된 커밋-공개 프로토콜 [145]: 커밋-공개 접근 방식은 클라이언트가 추측에 따라 트랜잭션을 커밋하고 후속 트랜잭션으로 인해 수익성이 있는 경우에만 이를 공개할 수 있다는 것입니다. 에이 커밋-공개 접근 방식의 최근 변형은 이에 대한 탄력성을 향상시킵니다. 일종의 잘못된 행동. 특히 TEX 프로토콜 [145]은 이 문제를 해결합니다. 암호화된 트랜잭션에 암호 해독 키가 포함되는 영리한 접근 방식을 사용합니다. 검증 가능한 지연 함수(VDF)를 계산하여 얻을 수 있습니다[53, 221]. 클라이언트인 경우 적시에 그녀의 거래를 해독하지 못하면 시스템의 다른 사람들이 해독합니다. 그녀를 대신하여 적당히 어려운 암호화 퍼즐을 해결합니다.• 임계값 암호화 [71, 190]: 이 방법은 DON이 수행할 수 있는 기능을 활용합니다. 임계값 암호화 작업. FSS가 공개 암호화를 유지한다고 가정합니다. 키 pkO와 oracle은 해당 개인 키를 서로 공유합니다. 그런 다음 클라이언트는 pkO에서 거래를 암호화하여 FSS로 보냅니다. FSS 주문 DON의 트랜잭션을 해독한 후 마지막으로 DON에 삽입합니다. MAINCHAIN은 고정된 순서로 진행됩니다. 따라서 암호화는 주문이 거래 내용을 기반으로 하는 것이 아니라 데이터 자체를 다음과 같은 경우에 사용할 수 있습니다. 필요합니다. 이 방법은 원래 Reiter와 Birman([190])에 의해 제안되었으며 나중에 Cachin 등에 의해 개선되었습니다. [71], 허가된 합의와 통합되었습니다. 프로토콜. 보다 최근의 연구에서는 임계값 암호화를 다음과 같이 사용하는 방법을 연구했습니다. 일반 메시지 [33, 97] 및 공유 데이터 [41]를 사용한 일반 계산을 위한 합의 수준 메커니즘. 커밋 공개 프로토콜과 비교하여 임계값 암호화는 단순한 서비스 거부 공격을 방지합니다(암호 해독에 드는 계산 비용을 고려할 때 주의가 필요함). DON이(가) 자체 속도로 자동으로 진행되도록 합니다. 추가 클라이언트 작업을 기다리고 있습니다. 거래는 해독된 후 즉시 검증될 수 있습니다. 또한 클라이언트는 모든 거래를 하나로 암호화합니다. DON의 키이며 통신 패턴은 다른 키와 동일하게 유지됩니다. 거래. 임계값 키를 안전하게 관리하고 노드를 변경하여 그러나 O는 추가적인 어려움을 초래할 수 있습니다. • 커밋된 비밀 공유 [97]: 거래 데이터를 암호화하는 대신 DON이 보유한 키인 경우 클라이언트는 이를 O의 노드에 대해 비밀 공유할 수도 있습니다. 하이브리드, 계산적으로 안전한 비밀 공유 방식을 사용하여 트랜잭션 먼저 임의의 키가 있는 대칭 암호를 사용하여 암호화됩니다. 해당 대칭 키만 공유되고 암호문은 DON에 제출됩니다. 클라이언트는 별도로 암호화된 메시지를 사용하여 O의 각 노드에 하나의 키 공유를 보내야 합니다. 나머지 프로토콜 단계는 임계값과 동일합니다. 단, 거래 데이터는 대칭형으로 해독됩니다. 공유에서 트랜잭션별 키를 재구성한 후 알고리즘을 사용합니다. 이 방법에는 공개 키 암호화 시스템의 설정이나 관리가 필요하지 않습니다. DON과 연결되어 있습니다. 그러나 클라이언트는 다음 노드에 대해 알고 있어야 합니다. O 그리고 그들 각각과 안전한 상황에서 통신합니다. 고객의 추가 부담. 암호화 방법은 정보로부터 완전한 보호를 제공하지만 제출된 트랜잭션에서 네트워크로 유출되는 경우 메타데이터를 숨기지 않습니다. 에 대한 예를 들어, 발신자의 IP 주소 또는 Ethereum 주소는 계속해서 사용될 수 있습니다. 전방 공격 및 기타 공격을 수행하는 적입니다. 다양한 프라이버시 강화 네트워크 계층(예: [52, 95, 107]) 또는 트랜잭션 계층에 배포된 기술, 예를 들어, [13, 65]는 이 목표를 달성하는 데 필요할 것입니다. 특정 작품의 영향 즉, 거래가 전송되는 계약에 대한 메타데이터를 (부분적으로) 숨길 수 있습니다.동일한 DON에서 많은 계약을 다중화함으로써. 암호화 은폐 거래 자체도 손상된 거래의 우선순위를 방해하지 않습니다. DON 노드가 거래 발신자와 공모하고 있습니다. 암호화 프로토콜에 의해 보장되는 안전한 인과관계는 모든 정책에 대한 질서 공정성 보장을 보완하며, 우리는 이 두 가지의 조합을 탐색할 계획입니다. 가능한 경우 방법. 상대방이 상당한 이점을 얻을 수 없는 경우 메타데이터를 관찰하면서 안전한 인과관계 보존 프로토콜을 함께 사용할 수 있습니다. 순진한 주문 방식도 마찬가지입니다. 예를 들어 oracle 노드는 트랜잭션을 작성할 수 있습니다. 중복 없이 L에게 수신 즉시 전달됩니다. 그러면 거래는 다음과 같습니다. L에 나타나는 순서에 따라 주문한 후 해독됩니다. 우리는 또한 공정한 주문을 집행하는 데 도움이 되는 방법으로 TEE 사용을 고려할 계획입니다. 에 대한 예를 들어, Tesseract [44]는 인과적 순서의 형태를 달성하는 것으로 볼 수 있지만 명시적인 형식으로 거래를 처리하는 TEE의 능력으로 강화되었습니다. 기밀을 유지합니다. 5.4 네트워크 계층 고려 사항 지금까지 FSS에 대한 설명은 주로 다음 사항을 집행하는 문제에 중점을 두었습니다. 최종 거래 순서는 네트워크에서 관찰된 순서와 일치합니다. 이후, 네트워크 계층 자체에서 발생할 수 있는 공정성 문제를 고려합니다. 기존 전자 시장의 고주파 거래자는 상당한 투자를 합니다. 우수한 네트워크 속도를 얻기 위한 리소스 [64], 암호화폐 거래소의 거래자는 유사한 행동 [90]을 나타냅니다. 네트워크 속도는 두 측면 모두에서 이점을 제공합니다. 다른 당사자의 거래를 관찰하고 경쟁 거래를 제출하는 행위. Flash Boys [155] 책에서 실제로 배포되고 대중화된 한 가지 치료법은 다음과 같습니다. IEX 거래소 [128]에서 처음 도입된 "과속 방지턱"은 나중에 다른 거래소에서도 도입되었습니다. [179]을 교환합니다(혼합된 결과 [19] 포함). 이 메커니즘은 시장 접근에 지연(IEX의 경우 350마이크로초)을 부과합니다. 속도. 경험적 증거. [128], 특정 거래 감소에 대한 효율성을 지원합니다. 일반 투자자의 비용. FSS는 단순히 비대칭을 구현하는 데 사용될 수 있습니다. 과속방지턱 - 들어오는 거래를 지연시키는 것입니다. Budish, Cramton 및 Shim [64]은 속도 이점을 활용한다고 주장합니다. 연속시장에서는 피할 수 없으며, 구조적 해결책을 주장합니다. 일괄 경매 기반 시장의 형태. 그러나 이 접근 방식은 널리 받아들여지지 않았습니다. 기존 거래 플랫폼에서. 기존 거래 시스템은 중앙 집중화되어 있으며 일반적으로 다음을 통해 거래를 받습니다. 단일 네트워크 연결. 대조적으로, 분산형 시스템에서는 다음이 가능합니다. 여러 유리한 지점에서 트랜잭션 전파를 관찰합니다. 결과적으로, P2P 네트워크에서는 네트워크 플러딩과 같은 행위를 관찰할 수 있습니다. 우리는 의도한다 개발자가 정책을 지정하는 데 도움이 되는 FSS에 대한 네트워크 계층 접근 방식을 탐색합니다. 그러한 바람직하지 않은 네트워크 행위를 금지합니다.5.5 엔터티 수준의 공정성 정책 주문 공정성과 안전한 인과성은 다음과 같은 거래에 대한 주문을 시행하는 것을 목표로 합니다. 생성되어 네트워크에 처음 제출된 시간을 존중합니다. 이러한 공정성 개념의 한계는 상대방이 공격하는 것을 방지하지 못한다는 것입니다. 거래가 많은 시스템이 넘쳐 이점을 얻는다. token 판매 [159]에서 효과적인 거래 저격을 수행하는 방법으로 야생에서 CDP(부채담보포지션) 청산으로 인한 혼잡 발생 [48]. 즉, 주문 공정성은 플레이어가 아닌 거래에 대한 공정성을 강화합니다. CanDID 시스템 [160]에 나와 있듯이 DECO와 같은 oracle 도구를 사용할 수 있습니다. 또는 노드 위원회(예: DON)와 함께 Town Crier를 통해 달성할 수 있습니다. 개인 정보를 보호하면서 다양한 형태의 Sybil 저항을 제공합니다. 사용자는 신원을 등록할 수 있습니다. 신원 자체를 공개하지 않고 고유성에 대한 증거를 제공합니다. 시빌 방지 자격 증명은 트랜잭션 주문을 강화하는 가능한 접근 방식을 제공합니다. 홍수 공격의 기회를 제한하는 방식으로 정책을 시행합니다. 예를 들어, token 판매는 등록된 사용자당 하나의 거래만 허용할 수 있습니다. 사회보장번호와 같은 국가 식별자의 고유성 증명이 필요합니다. 이러한 접근 방식이 완벽하지는 않지만 트랜잭션 플러딩 공격을 완화하는 데 유용한 정책이 될 수 있습니다.
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.
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 솔루션에 대한 분산형 리소스 지원을 제공합니다. 우리는 분산형 Oracle 네트워크 트랜잭션 실행 프레임워크(DONTEF) 또는 줄여서 TEF라고 부릅니다. 현재 DeFi 계약에 대한 업데이트 빈도는 메인 체인 지연 시간으로 인해 제한됩니다. 예를 들어 Ethereum [104]의 10-15초 평균 블록 간격과 체인에 대량의 데이터를 푸시하고 계산/전송 처리량이 제한됨 샤딩 [148, 158, 232] 및 레이어 2 실행 [5, 12, 121, 141, 169, 186, 187]. 거래 시간이 훨씬 빠른 blockchains라도, 예를 들어 [120]은 오프체인 계산 [168]과 관련된 확장 전략을 제안했습니다. TEF는 이러한 레이어 1/MAINCHAIN 시스템에 대한 레이어 2 리소스 역할을 하기 위한 것입니다. TEF를 사용하면 DONs는 MAINCHAIN 계약에서 더 빠른 업데이트를 지원할 수 있습니다. 메인 체인이 제공하는 주요 신뢰 보증을 유지합니다. TEF는 지원할 수 있습니다 rollups11을 포함한 다양한 레이어 2 실행 기술 및 패러다임 중 하나 낙관적인 rollups, Validium 등 및 DON이 포함된 임계 신뢰 모델 노드는 트랜잭션을 실행합니다. TEF는 FSS를 보완하며 이를 지원하기 위한 것입니다. 즉, 어떤 TEF에서 실행되는 애플리케이션은 FSS를 사용할 수 있습니다. 11영지식 증명이 반드시 필요하지 않기 때문에 종종 "zk-rollups"라고 부르는데 이는 잘못된 명칭입니다.
6.1 TEF 개요 TEF는 고성능 하이브리드의 구축 및 실행을 위한 설계 패턴입니다. smart contract SC. 하이브리드 smart contracts의 기본 아이디어에 따라 TEF에는 다음이 포함됩니다. SC를 두 부분으로 분해: (1) TEF 맥락에서 앵커라고 부르는 것 MAINCHAIN에서 SCa를 계약하고 (2) DON 로직은 TEF 실행 파일을 호출하도록 선택합니다. 여기서는 SCa의 조합으로 구현된 논리적 계약을 나타내기 위해 SC를 사용합니다. 그리고 실행하십시오. (위에서 언급했듯이 우리는 SC를 자동으로 이러한 구성 요소로 변환합니다.) TEF 실행 파일 exect는 SC에서 사용자의 트랜잭션을 처리하는 엔진입니다. 그것 DON에서 실행되므로 성능이 뛰어난 방식으로 실행될 수 있습니다. 여기에는 여러 가지 기능이 있습니다. • 트랜잭션 수집: Exect는 사용자의 트랜잭션을 수신하거나 가져옵니다. 그렇게 할 수 있다 직접, 즉 DON에 대한 거래 제출을 통해 또는 MAINCHAIN을 통해 MS를 이용한 멤풀. • 빠른 거래 실행: Exect는 자산과 관련된 거래를 처리합니다. SC. 즉, DON에서 로컬로 수행됩니다. • 빠르고 저렴한 oracle / 어댑터 액세스: exect는 oracle 보고서에 대한 기본 액세스 권한을 가집니다. 예를 들어 더 빠르고 저렴하며 더 정확한 자산으로 이어지는 기타 어댑터 데이터 MAINCHAIN 실행보다 가격이 책정됩니다. 게다가 오프체인 oracle 액세스가 감소합니다. oracle의 운영 비용, 즉 시스템 사용 비용 값비싼 온체인 스토리지. • 동기화: Exect는 주기적으로 DON의 업데이트를 MAINCHAIN에 푸시하여 SCa를 업데이트합니다. 앵커 계약은 SC의 MAINCHAIN 프런트 엔드입니다. SC의 신뢰도가 높은 구성 요소로서 다음과 같은 여러 목적을 수행합니다. • 자산 보관: 사용자의 자금은 SCa에 예치, 보관 및 인출됩니다. • 동기화 확인: SCa는 실행 시 상태 업데이트의 정확성을 확인할 수 있습니다. 동기화(예: rollups에 연결된 SNARK). • 가드레일: SCa에는 손상이나 고장으로부터 보호하기 위한 조항이 포함될 수 있습니다. 예를 들어. (자세한 내용은 섹션 7을 참조하세요.) TEF에서 사용자의 자금은 MAINCHAIN에 관리됩니다. 즉, DON 자체는 비관리적입니다. 선택한 동기화 메커니즘(아래 참조)에 따라 사용자는 다음이 필요할 수 있습니다. 정확한 oracle 보고서와 MAINCHAIN과의 적시 동기화를 위해서만 DON을 신뢰하십시오. 결과적인 신뢰 모델은 주문서 기반 DEX(예: [2])의 모델과 매우 유사합니다. 오늘날 여기에는 일반적으로 주문 매칭을 위한 오프체인 구성요소와 청산 및 결제를 위한 온체인 구성요소가 포함됩니다.지불 시스템의 용어를 사용하려면 exec를 구성 요소로 생각할 수 있습니다. SC는 청산을 담당하고 SCa는 결제를 담당합니다. 회로도는 그림 13을 참조하세요. TEF의 묘사. 그림 13: TEF 회로도. 이 예에서 트랜잭션은 mempool을 통과합니다. MS를 통해 MAINCHAIN을 DON로 보냅니다. TEF 혜택: TEF는 세 가지 주요 이점을 제공합니다. • 고성능: SC는 MAINCHAIN보다 DON의 훨씬 높은 처리량을 상속합니다. 거래 및 oracle 보고서 모두에 대해. 또한 Exect는 MAINCHAIN 단독 구현보다 트랜잭션을 더 빠르게 처리하고 oracle 보고서에 적시에 응답할 수 있습니다. • 낮은 수수료: 동기화 프로세스는 트랜잭션 처리보다 시간에 덜 민감하며 트랜잭션은 DON에서 MAINCHAIN으로 일괄적으로 전송될 수 있습니다. 결과적으로, 이 접근 방식을 사용하면 트랜잭션당 온체인 수수료(예: 가스 비용)가 MAINCHAIN에서만 실행되는 계약보다 훨씬 낮습니다. • 기밀성: DON의 기밀성 메커니즘을 가져올 수 있습니다. SC에 곰.
TEF 제한사항: TEF의 한 가지 제한 사항은 순간적인 기능을 지원하지 않는다는 것입니다. MAINCHAIN에서만 발생하는 출금: 출금 요청을 보낼 때 SCa에 대해 사용자는 exec가 포함된 상태 업데이트를 수행할 때까지 기다려야 할 수도 있습니다. 인출 거래가 승인되기 전에. 우리는 부분적인 해결 방법을 논의합니다. 그러나 섹션 6.2. TEF의 또 다른 제한 사항은 DeFi의 원자 구성을 지원하지 않는다는 것입니다. MAINCHAIN 계약, 특히 여러 DeFi을 통해 자산을 라우팅하는 기능 단일 거래로 계약을 체결합니다. 그러나 TEF는 이러한 원자성을 지원할 수 있습니다. DeFi 계약은 동일한 DON에서 실행됩니다. 또한 이 문제를 해결하는 몇 가지 방법에 대해서도 논의합니다. 6.2절의 문제. 6.2 거래 라우팅 SC에 대한 거래는 사용자가 DON로 직접 보내거나 다음을 통해 라우팅될 수 있습니다. MAINCHAIN의 멤풀(FSS를 통해). 4가지의 서로 다른 거래 유형이 있으며, 각각 그 중 다른 처리가 필요합니다. 계약 내 거래: TEF는 가스 역학의 복잡성을 회피하기 때문에 SC에 트랜잭션 처리에 있어 다른 것보다 더 많은 유연성을 제공합니다. 레이어-1 계약에서 사용 가능합니다. 예를 들어, Ethereum의 mempool 트랜잭션이 있는 동안 가스 가격이 더 높은 새로운 거래로 덮어쓸 수 있으며, SC는 SC 내 자산에서 운영되는 거래가 눈에 보이는 즉시 권위 있는 거래로 처리할 수 있습니다. 멤풀에서. 결과적으로 SC는 거래가 확인될 때까지 기다릴 필요가 없습니다. 블록 내에서 지연 시간이 크게 단축됩니다. 프록시: 사용자는 지갑 계약을 통해 SC에 거래 τ를 보내거나 MAINCHAIN의 다른 계약. DON에서 실행을 시뮬레이션하는 것이 가능합니다. MAINCHAIN에서 τ를 수행하여 SC에 대한 후속 트랜잭션이 발생하는지 여부를 결정합니다. 그렇다면 τ는 SC에 대한 다른 트랜잭션과 순서를 지정할 수 있습니다. 몇 가지가 있습니다 DON이 그러한 거래를 식별하는 방법에 대한 가능성: (1) DON은 시뮬레이션할 수 있습니다 mempool의 모든 트랜잭션(비용이 많이 드는 접근 방식) (2) 특정 계약 또는 지갑과 같은 계약 유형은 DON에 의해 모니터링을 위해 나열될 수 있습니다. 또는 (3) 사용자는 다음을 수행할 수 있습니다. DON 검사를 위해 거래에 주석을 답니다. 단일 거래가 두 거래와 상호 작용할 때 문제는 더욱 복잡해집니다. SC1 및 SC2 계약은 둘 다 Fair Sequencing Services를 사용하고 호환되지 않는 주문 정책을 가지고 있습니다. 예를 들어 DON은 가장 최근에 τ를 시퀀스할 수 있습니다. 그것은 둘 다와 호환됩니다. 예금: MAINCHAIN 자산을 SC에 예치하는 거래는 SC가 이를 유효한 것으로 처리하기 전에 블록에서 확인되어야 합니다. 채굴이 감지되면 자산(예: Ether)을 SCa로 보내는 거래는 즉시 확인할 수 있습니다.보증금. 예를 들어, DON에 대해 현재 oracle 보고된 가격을 적용할 수 있습니다. 자산. 인출: 위에서 언급했듯이 TEF의 한계는 인출이 항상 즉시 실행될 수 없다는 것입니다. rollup 유형 실행 모델에서는 철회가 요청은 안전하게 처리되기 위해 다른 트랜잭션과 순서대로 처리되어야 합니다. 즉, 롤업되어야 합니다. 처리됨. 그러나 이 제한 사항에 대한 몇 가지 부분적인 해결 방법이 있습니다. DON이 인출 트랜잭션까지 rollup 유효성 증명을 신속하게 계산할 수 있다면 mempool exect에서 사용자의 트랜잭션 τ를 관찰하면 일종의 유익한 선행 실행인 더 높은 가스 가격으로 τ에 대한 상태 업데이트 트랜잭션 τ'를 보낼 수 있습니다. τ'가 멤풀에 도달하기 전에 τ가 채굴되지 않으면 τ'가 τ보다 먼저 발생하고 τ가 채굴됩니다. 승인된 철회에 영향을 미칩니다. 상태 업데이트를 계산하기 위해 DON을 사용하는 TEF 변형에서(참조: 아래의 임계값 서명 변형), 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] 참조) 아래에서는 세 가지 주요 속성과 관련하여 이러한 동기화 옵션을 비교합니다. TEF: • 데이터 가용성: SC의 상태는 어디에 저장됩니까? 최소한 세 가지 옵션이 있습니다. TEF에서 사용 가능: MAINCHAIN, DON 또는 일부 타사 저장소에서 사용 가능 IPFS와 같은 공급자. 그들은 다양한 보안 보장, 가용성을 달성합니다. 수준 및 성능 프로필. 간략하게, MAINCHAIN에 상태를 저장하면 온체인 감사 가능성을 제공하고 상태 가용성에 대한 모든 당사자에 대한 의존성을 제거합니다. 반면에 상태를 오프체인에 저장하면 저장 비용을 줄이고 성능을 향상할 수 있습니다. 처리량은 신뢰할 수 있는 스토리지 제공업체(DON 또는 제3자)의 비용으로 데이터 가용성. 물론 이러한 옵션을 결합한 유연한 모델도 있습니다. 가능합니다. 표 1에는 필요한 데이터 가용성 형식이 나와 있습니다.• 정확성 보장: SCa는 업데이트의 정확성을 어떻게 확인합니까? exect에 의해 밀렸나요? 이는 Exect 및 SCa의 계산 부하에 영향을 미치며 동기화 대기 시간(아래 참조) • 지연 시간: 동기화 지연 시간에는 세 가지 요인이 있습니다. (1) 소요 시간 동기화 트랜잭션 τsync를 생성하기 위해; (2) τsync에 걸리는 시간 MAINCHAIN에서 확인됩니다. (3) τsync가 효과를 발휘하는 데 걸리는 시간 SCa. 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]은 상태 전환이 다음에 의해 영향을 받는 프로토콜입니다. 일괄 거래는 오프체인으로 계산됩니다. 그런 다음 상태 변경이 전파됩니다. MAINCHAIN에. rollups를 구현하기 위해 앵커 smart contract SCa는 실제 상태의 압축 표현 Rstate(예: Merkle 루트)를 저장합니다. 동기화하려면 Exec가 τsync =를 보냅니다. (티, R' 상태)를 SCa로 변환합니다. 여기서 T는 마지막 이후 처리한 트랜잭션 집합입니다.동기화 및 R' 상태는 다음을 적용하여 계산된 새 상태의 간략한 표현입니다. T의 이전 상태 Rstate로의 트랜잭션. SCa가 τsync에서 상태 업데이트를 확인하는 방법에는 두 가지 인기 있는 변형이 있습니다. 첫 번째 (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의 모든 데이터를 유지하지 않습니다. 구체적으로 exec는 새 항목만 보냅니다. 상태 및 증거는 있지만 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. TEF 동기화의 TEE 기반 변형은 다음을 통해 구현할 수 있습니다. 기술을 사용하여 (zk-)rollups 또는 Validium의 증명을 TEE 증명으로 대체합니다. [80]에서. rollups 및 Validium에서 사용되는 영지식 증명과 비교할 때 TEE는 더 성능이 좋습니다. 임계값 서명과 비교하여 TEE는 다음의 복잡성을 제거합니다. 원칙적으로 단 하나의 TEE만 필요하므로 임계값 ECDSA 서명을 생성합니다. 참여. 그러나 TEE를 사용하면 추가 하드웨어 종속 신뢰 가정이 도입됩니다. TEE를 임계값 서명과 결합하여 복원력을 생성할 수도 있습니다. 이 보호 조치는 TEE 인스턴스의 일부가 손상되는 것을 방지합니다. 임계값 ECDSA 서명 생성의 복잡성이 다시 도입되었습니다. 추가적인 유연성: 이러한 동기화 옵션은 다음과 같은 방법으로 더 많은 유연성을 제공하도록 구체화될 수 있습니다. • 유연한 트리거링: TEF 애플리케이션은 다음 조건을 결정할 수 있습니다. 동기화가 트리거됩니다. 예를 들어 동기화는 배치 기반일 수 있습니다. N개의 트랜잭션마다, 시간 기반(예: 10개 블록마다) 또는 이벤트 기반(예: 발생) 목표 자산 가격이 크게 움직일 때마다. • 부분 동기화: 가능하며 어떤 경우에는 바람직합니다(예: rollups, 부분 동기화는 대기 시간을 줄일 수 있음) 작은 것의 빠른 동기화를 제공하기 위해 상태 양, 아마도 주기적으로만 전체 동기화를 수행합니다. 예를 들어, exect는 SCa에서 사용자 잔액을 업데이트하여 출금 요청을 승인할 수 있습니다. MAINCHAIN 상태를 별도로 업데이트하지 않고. 6.4 재구성 네트워크 불안정 또는 51% 공격으로 인한 블록체인 재구성 메인체인의 무결성에 위협이 될 수 있습니다. 실제로, 적들은 다음과 같은 방법을 사용했습니다. 이중 지출 공격을 가하기 위해 [34]. 주요 체인에 대한 이러한 공격은 장착이 까다로우나 일부 체인에서는 여전히 실행 가능합니다([88]). MAINCHAIN과 독립적으로 작동하기 때문에 DON는 흥미로운 이점을 제공합니다. 다음과 관련된 재구성에 대한 일부 보호를 관찰하고 제공할 가능성 공격. 예를 들어, DON는 MAINCHAIN의 의존 계약 SC에 일부 임계 길이 τ의 경쟁 포크의 존재를 보고할 수 있습니다. DON은 추가적으로 가능합니다. 12보충 세부 정보는 부록 B.2.1에서 확인할 수 있습니다. 이해하는 데에는 필요하지 않습니다.
PoW 또는 PoS 설정에서 그러한 포크가 존재한다는 증거를 제공합니다. 는 계약 SC는 일정 기간 동안 추가 거래 실행을 중단하는 등 적절한 방어 조치를 구현할 수 있습니다(예: 거래가 이중 지출을 블랙리스트에 올리도록 허용). 자산). 51% 공격을 가하는 상대는 검열을 시도할 수 있지만 DON의 보고에 따라 SC의 대책은 정기적인 보고를 요구하는 것입니다. 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.
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 데이터 소스 인증 oracles의 현재 운영 모델은 데이터 소스가 거의 없다는 사실로 인해 제약을 받습니다. TLS가 기본적으로 서명하지 않기 때문에 생략한 데이터에 디지털 서명을 합니다. 데이터. TLS는 "핸드셰이크" 프로토콜에서 디지털 서명을 사용합니다. 서버와 클라이언트 사이의 공유 키). 따라서 HTTPS 지원 서버에는 인증서가 있습니다. 원칙적으로 데이터 서명에 사용할 수 있는 공개 키에 대해 일반적으로 사용하지는 않습니다. 데이터 서명을 지원하는 인증서입니다. 결과적으로 DON의 보안은 다음과 같습니다. 오늘날의 oracle 네트워크에서는 데이터에서 데이터를 충실하게 중계하는 oracle 노드에 의존합니다. 계약에 대한 소스입니다. Chainlink의 신뢰 최소화를 위한 우리 비전의 중요한 장기 구성 요소에는 데이터 서명을 위한 도구 및 표준 지원을 통한 더욱 강력한 데이터 소스 인증이 포함됩니다. 데이터 서명은 엔드투엔드 무결성 보장을 강화하는 데 도움이 될 수 있습니다. 원칙적으로 계약이 데이터가 직접 서명한 데이터 D 조각을 입력으로 수락하는 경우
그림 14: 이 섹션에서 논의된 신뢰 최소화 메커니즘의 위치. 1⃝데이터 소스는 데이터의 기능을 종속 항목에 전달하는 2⃝DON에 데이터를 제공합니다. 3⃝smart contract. 또한 DON 또는 oracle 네트워크에는 4⃝노드가 포함되어 있습니다. 보상 노드, 가드 등을 위한 MAINCHAIN의 smart contract 관리 레일 등. 소스가 있으면 oracle 네트워크는 D를 실질적으로 변조할 수 없습니다. 다양한 격려 OpenID Connect를 포함하여 이러한 데이터 서명을 활성화하려는 노력이 나타났습니다. 주로 사용자 인증을 위해 설계되었습니다. [9], TLS-N, 학술 프로젝트 TLS 인증서 및 TLS 증거 확장 [63]을 용도 변경하여 TLS [191]을 확장합니다. OpenID Connect가 일부 채택되었지만 TLS Evidence Extensions는 TLS-N은 아직 채택되지 않았습니다. 데이터 소스 인증의 또 다른 잠재적인 방법은 게시자의 자체 인증을 사용하는 것입니다. AMP(Accelerated Mobile Pages) 프로토콜 [225]의 일부로 콘텐츠 전달 네트워크에서 캐시할 수 있는 서명된 HTTP 교환(SXG) [230]. Chrome 모바일 브라우저는 AMP 캐시된 SXG의 콘텐츠를 마치 AMP에서 제공되는 것처럼 표시합니다. 캐시 서버 도메인 대신 게시자의 자체 네트워크 도메인. 이러한 브랜딩 인센티브는 CloudFlare의 실제 URL [83] 및 Google의 amppackager [124]과 같은 서비스를 사용하여 상대적으로 쉽게 활성화할 수 있다는 점과 결합되어 캐시된 뉴스 콘텐츠에 SXG를 널리 채택하게 할 수 있습니다. Chainlink oracles가 유효한 SXG에 보고된 뉴스 가치가 있는 이벤트에서 트리거되는 방법입니다. 뉴스 게시자의 AMP 캐시 SXG는 빠른 템포에는 유용하지 않습니다. 거래 데이터에 대한 보고서와 같은 애플리케이션은 사용자 정의를 위한 안전한 소스가 될 수 있습니다. 기상 이변이나 선거 결과와 같은 실제 사건과 관련된 계약. 우리는 간단한 배포, 성숙한 도구, 유연성이 핵심이라고 믿습니다. 데이터 소스 서명 가속화. 데이터 공급자가 Chainlink 노드를 다음과 같이 사용할 수 있도록 설정 인증된 API 프런트 엔드는 유망한 접근 방식으로 보입니다. 우리는네트워크 참여 여부에 관계없이 노드가 이 모드에서 작동하는 옵션 본격적인 oracle로. 우리는 이 기능을 인증된 데이터 생성이라고 부릅니다. (ADO). ADO와 함께 Chainlink 노드를 사용하면 데이터 소스가 이점을 얻을 수 있습니다. Chainlink 커뮤니티에서 개발한 경험과 도구를 통해 디지털 기능을 추가했습니다. 기존 오프체인 API 제품군에 서명 기능을 제공합니다. 그들은 달리기를 선택해야 할까요? 노드를 oracles로 사용하면 잠재적인 새로운 수익원을 추가로 열 수 있습니다. 기존 데이터 제공자와 동일한 모델(예: Kraken [28], Kaiko [140]) 다른 것들은 Chainlink 노드를 실행하여 체인에서 API 데이터를 판매합니다. 7.1.1 인증된 데이터 생성의 한계 데이터 소스에 의한 디지털 서명은 인증을 강화하는 데 도움이 될 수 있지만 그 자체로는 oracle의 모든 자연스러운 보안 또는 운영 목표를 달성하는 데 충분하지 않습니다. 네트워크. 우선, 주어진 데이터 D 조각은 여전히 강력하고 시기적절하게 전달되어야 합니다. 데이터 소스에서 smart contract 또는 다른 데이터 소비자로 가는 방법. 즉, 에서도 종속 항목에 사전 프로그래밍된 키를 사용하여 모든 데이터가 서명되는 이상적인 설정 계약을 체결하더라도 소스로부터 데이터를 안정적으로 전달하려면 DON이 여전히 필요합니다. 계약에. 또한 계약이나 기타 oracle-데이터가 소비자는 계산된 다양한 기능의 인증된 출력에 액세스하기를 원합니다. 두 가지 주요 이유는 소스 데이터입니다. • 기밀성: 데이터 소스 API는 민감하거나 독점적인 데이터를 제공할 수 있습니다. 체인에 공개되기 전에 수정하거나 정리해야 합니다. 그러나 서명된 데이터를 수정하면 서명이 무효화됩니다. 다른 것을 넣어 그런데 순진한 ADO와 데이터 삭제는 호환되지 않습니다. 예제 3에 나와 있습니다. 향상된 형태의 ADO를 통해 이 둘을 어떻게 조화시킬 수 있는지 알아보세요. • 데이터 소스 오류: 오류와 실패 모두 데이터 소스에 영향을 미칠 수 있으며 디지털 서명은 두 가지 문제를 모두 해결하지 못합니다. [98], Chainlink은 처음부터 이러한 결함을 해결하기 위한 메커니즘인 중복성이 이미 포함되어 있습니다. oracle 네트워크에서 발행한 보고서는 일반적으로 여러 네트워크의 결합된 데이터를 나타냅니다. 소스. 이제 소스 데이터의 기밀성을 강화하고 여러 소스의 데이터를 안전하게 결합하기 위해 ADO 설정에서 탐색 중인 구성표에 대해 논의합니다. 7.1.2 기밀성 데이터 소스는 원하는 API의 전체 영역을 예상하고 제공하지 못할 수 있습니다. 사용자에 의해. 특히 사용자는 사전 처리된 데이터에 액세스하여 다음을 보장할 수 있습니다. 기밀성. 다음 예에서는 문제를 보여줍니다.예시 3. Alice는 다음과 같은 DID(분산 신원) 자격 증명을 얻고 싶어합니다. 그녀는 18세 이상이어야 합니다(예를 들어 대출을 받을 수 있음). 해야 할 일 따라서 그녀는 자신의 나이에 대한 사실을 DID 자격 증명 발급자에게 증명해야 합니다. Alice는 자신이 거주하는 주의 DMV(Department of Motor Vehicles)의 데이터를 사용하기를 원합니다. 목적으로 웹사이트. DMV는 그녀의 생년월일 기록을 가지고 있으며 다음 형식의 디지털 서명된 증명 A: A = {이름: Alice, DoB: 1999년 2월 16일}. 이 예에서 증명 A는 Alice가 DID에 증명하기에 충분할 수 있습니다. 하지만 이는 민감한 정보를 불필요하게 유출합니다: Alice의 정확한 DoB. 이상적으로는 Alice가 DMV에서 원하는 것은 자동차 보험에 서명하는 것입니다. “앨리스는 18세 이상입니다.”라는 간단한 진술 A'입니다. 즉, 그녀는 그녀의 생일 X에 대한 함수 G의 출력. 여기서 (비공식적으로) A′ = G(X) = True인 경우 현재 날짜 −X ≥18년; 그렇지 않으면 G(X) = 거짓입니다. 일반화하자면, Alice는 데이터 소스로부터 서명된 데이터를 요청할 수 있기를 원합니다. 다음 형식의 증명 A': A′ = {이름: Alice, Func: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(가격 데이터 중위화) 가격 피드 제공, 즉 하나의 가치 자산(예: ETH)을 다른 자산(예: USD)에 비해 oracle 네트워크는 일반적으로 거래소 등 다양한 소스에서 현재 가격을 얻습니다. oracle 네트워크 일반적으로 이러한 값의 중앙값을 종속 계약 SC에 보냅니다. 데이터 서명이 있는 환경에서 올바르게 작동하는 oracle 네트워크는 데이터 소스 S = {S1, . . . , SnS} 값의 시퀀스 V = {v1, v2, . . . , vnS} 에서 소스별 서명이 수반되는 nS 소스 Σ = {σ1, σ2, . . . , σnS}. 시 서명을 확인한 후 가격 v = 중앙값(V)을 SC로 전송합니다.불행하게도 oracle 네트워크가 중앙값을 전송하는 간단한 방법은 없습니다. v가 올바르게 계산되었다는 간결한 증거 σ와 함께 예제 4의 v 값을 SC에 전달합니다. 과도하게 서명된 입력. 순진한 접근 방식은 SC에서 모든 nS 데이터 소스의 공개 키를 인코딩하는 것입니다. 그런 다음 oracle 네트워크는 (V, Σ)를 중계하고 SC가 V의 중앙값을 계산하도록 허용합니다. 그러나 이는 크기 O(nS)의 증명 σ가 됩니다. 즉, σ는 간결하지 않습니다. 또한 모든 서명을 확인해야 하는 SC에 높은 가스 비용이 발생합니다. Σ. 이와 대조적으로 SNARK를 사용하면 올바르게 결합된 인증된 소스 값에 대한 간결한 증거가 가능합니다. 실제로 실행 가능할 수도 있지만 상당히 높은 수준을 부과합니다. 증명자의 계산 비용과 체인의 가스 비용이 다소 높습니다. 사용 Town Crier도 가능하지만 TEE를 사용해야 하므로 모든 사람에게 적합하지는 않습니다. 사용자의 신뢰 모델. 소스에서 결합된 데이터에 서명하는 일반적인 문제에 대한 솔루션을 구성하는 유용한 개념은 기능 서명으로 알려진 암호화 도구입니다[59, 132]. 간단히 말해서, 기능적 서명을 통해 서명자는 다음과 같은 서명 기능을 위임할 수 있습니다. 위임자는 서명자가 선택한 함수 F 범위의 메시지에만 서명할 수 있습니다. 우리는 부록 D에서 이 기능적 제약이 어떻게 범위를 제한하는 역할을 할 수 있는지 보여줍니다. 데이터 소스에서 서명된 값의 함수로 DON에서 내보내는 보고서 값입니다. 또한 정확성에 대한 완화된 요구 사항을 포함하지만 잠재적으로 훨씬 더 성능이 뛰어난 이산화된 기능 시그니처라고 하는 새로운 기본 요소를 도입합니다. SNARK와 같은 접근 방식보다. 소스 인증을 포함하는 방식으로 데이터 소스를 결합하는 문제 출력은 CoinCap, CoinMarketCap, CoinGecko와 같은 데이터 수집자에도 적용됩니다. 다양한 거래소로부터 데이터를 얻는 CryptoCompare 등 경우에 따라 공개하는 방법론을 사용하여 부피에 따른 무게 다른 경우에는 독점적입니다. 다음과 같은 값을 게시하려는 수집자 소스 인증은 노드 집합과 동일한 문제에 직면합니다. 소스 데이터. 7.1.4 소스 데이터 처리 정교한 smart contract은 사용자 정의 집계 통계에 의존할 가능성이 높습니다. 많은 자산에 대한 최근 가격 기록의 변동성과 같은 기본 데이터 소스 또는 관련 사건에 대한 뉴스의 텍스트 및 사진. DON에서는 계산 및 대역폭이 상대적으로 저렴하기 때문에 이러한 통계는 — 입력이 많은 복잡한 기계 학습 모델이라도 blockchain에 대한 출력 값이 충분히 간결하다면 경제적으로 처리할 수 있습니다. DON 참가자가 서로 다를 수 있는 계산 집약적인 작업의 경우 복잡한 입력에 대한 견해가 있는 경우 결과를 계산하기 전에 입력에 대한 합의를 확립하기 위해 DON 참가자 간의 추가 의사소통이 필요할 수 있습니다. 최종 값이 입력에 의해 완전히 결정되는 한, 입력 합의가 확립되면 각 참가자는 간단히 값을 계산하여 다른 참가자에게 알릴 수 있습니다.참가자는 부분 서명을 사용하거나 이를 수집자에게 보냅니다. 7.2 DON 신뢰 최소화 우리는 DON 구성 요소에 대한 신뢰를 최소화하는 두 가지 주요 방법을 구상합니다. 장애 조치 클라이언트 및 소수 보고서. 7.2.1 장애 조치 클라이언트 암호화 및 분산 시스템 문헌의 적대적 모델은 일반적으로 노드의 하위 집합을 손상(즉, 손상)할 수 있는 공격자를 고려합니다. 예를 들어 많은 BFT 프로토콜의 경우 1/3 미만입니다. 흔히 관찰되지만, 모든 노드가 동일한 소프트웨어를 실행하는 경우 치명적인 공격을 식별한 공격자는 원칙적으로 모든 노드를 어느 정도 동시에 손상시킵니다. 이 설정은 종종 소프트웨어 단일 문화라고 합니다 [47]. 문제를 해결하기 위해 소프트웨어 및 소프트웨어 구성을 자동으로 다양화하기 위한 다양한 제안이 제시되었습니다(예: [47, 113]). [47]에 명시된 바와 같이, 그러나 소프트웨어 다양성은 복잡한 문제이므로 신중한 고려가 필요합니다. 예를 들어, 소프트웨어 다양화는 다음과 같은 경우 단일 문화보다 더 나쁜 보안을 초래할 수 있습니다. 시스템의 공격 표면을 증가시켜 가능한 공격 벡터를 초과합니다. 그것이 제공하는 보안 이점. 우리는 강력한 장애 조치 클라이언트(즉, 노드가 연결되는 클라이언트)에 대한 지원이 가능하다고 믿습니다. 재앙이 닥쳤을 때 전환할 수 있다는 점은 특히 매력적인 형태입니다. 소프트웨어 다양화. 장애 조치 클라이언트는 잠재적 벡터 수를 늘리지 않습니다. 공격의 위험이 있습니다. 메인라인 소프트웨어로 배포되지 않기 때문입니다. 그들은 분명한 이점을 제공합니다. 그러나 두 번째 방어선으로 사용됩니다. 우리는 DONs에서 장애 조치 클라이언트를 다음과 같이 지원할 계획입니다. 단일 클라이언트에 대한 보안 의존도를 줄이는 주요 수단입니다. Chainlink에는 이미 강력한 장애 조치 클라이언트 시스템이 마련되어 있습니다. 우리의 접근 방식 철저한 테스트를 거친 이전 클라이언트 버전을 유지 관리하는 작업이 포함됩니다. 예를 들어 현재 OCR(오프체인 보고)을 기본 클라이언트로 사용하는 Chainlink 노드에는 지원이 포함됩니다. 필요한 경우 Chainlink의 이전 FluxMonitor 시스템용. 일부 사용 중이던 FluxMonitor는 보안 감사와 현장 테스트를 받았습니다. 그것은 동일한 것을 제공합니다 OCR 기능을 더 높은 비용으로 제공합니다. 비용은 필요할 때만 발생합니다. 7.2.2 마이너리티 리포트 충분히 큰 소수 집합이 주어지면 소수(다수의 불법 행위를 관찰하는 정직한 노드의 일부)가 소수를 생성하는 데 도움이 될 수 있습니다. 보고. 이는 종속 계약 SC 온체인에 전달되는 병렬 보고서 또는 플래그입니다. Ominority에 의해. SC는 자체 계약별 정책에 따라 이 플래그를 사용할 수 있습니다. 예를 들어, 생명력이나 반응성보다 안전이 더 중요한 계약의 경우 소수 보고서로 인해 계약에서 보충 보고서를 요청할 수 있습니다. 다른 DON에서 연결하거나 회로 차단기를 작동시키세요(다음 섹션 참조).다수가 정직할 때에도 소수 보고서는 중요한 역할을 할 수 있으며, 왜냐하면 모든 보고서 집계 체계는 기능적 서명을 사용하더라도 oracle 또는 데이터 오류에 대한 복원력을 보장하기 위해 임계값 방식으로 작동합니다. 에서 즉, 입력 내용을 기반으로 유효한 보고서를 생성하는 것이 가능해야 합니다. kS < nS oracles, 일부 임계값 kS의 경우. 이는 손상된 DON에 일부 오류가 있음을 의미합니다. 다음 중에서 선호하는 kS 값을 선택하여 보고서 값을 조작할 수 있는 위도 모든 소스가 정직하더라도 oracle 전체 세트에 의해 V에서 보고된 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가 더 높은 보안을 제공하는 상황에 결과 메커니즘을 적용합니다. 플랫폼보다 그 반대입니다.) 따라서 자연스러운 신뢰 최소화 전략에는 MAINCHAIN 프런트 엔드에서 smart contracts의 모니터링 및 안전 장치 메커니즘 구현이 포함됩니다. DON의 경우 또는 종속 계약 SC에서 직접. 우리는 이러한 메커니즘을 다음과 같이 지칭합니다. 가드레일을 확인하고 여기에 가장 중요한 사항을 열거하세요. • 회로 차단기: SC는 상태 업데이트 자체의 특성에 따라 상태 업데이트를 일시 중지하거나 중지할 수 있습니다(예: 순차 업데이트에 대한 큰 차이). 보고서) 또는 기타 입력을 기반으로 합니다. 예를 들어 회로 차단기가 작동할 수 있습니다. oracle 보고서가 시간이 지남에 따라 믿을 수 없을 정도로 변하는 경우입니다. 회로 차단기가 또한 소수 보고서에 의해 넘어질 수도 있습니다. 따라서 회로 차단기는 DONs를 방지할 수 있습니다. 심하게 잘못된 보고를 하는 것으로부터. 회로 차단기는 추가 개입을 고려할 시간을 제공할 수 있습니다. 아니면 운동을 했는지. 그러한 개입 중 하나는 탈출구입니다. • 탈출구: 일련의 관리인, 커뮤니티 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에 있으며 앞으로도 계속될 수 있습니다. DON을 배포하더라도 그렇게 할 수 있습니다. 한 가지 예는 결제 메커니즘입니다. oracle 노드 공급자(DON 노드)의 경우. DON MAINCHAIN의 프런트 엔드 계약 가드레일과 같이 주기적으로 영향을 받을 수 있는 추가 메커니즘이 포함되어 있습니다. 수정. 우리는 진화적 메커니즘과 비상사태라는 두 가지 종류의 거버넌스 메커니즘을 예상합니다. 진화적 거버넌스: Chainlink 생태계에 대한 많은 수정 사항은 다음과 같습니다. 구현이 긴급한 문제가 되지 않도록: 성능 개선, 기능 향상, (긴급하지 않은) 보안 업그레이드 등. Chainlink이(가) 거버넌스에 더 많은 참여자를 향해 점진적으로 나아감에 따라 우리는 더 많은 또는 이러한 변경 사항의 대부분은 해당 변경 사항의 영향을 받은 특정 DON 커뮤니티에 의해 비준됩니다. 변화. 그 동안 그리고 아마도 궁극적으로는 병렬 메커니즘으로서 우리는 다음과 같이 믿습니다. 시간적 최소 특권의 개념은 진화적 거버넌스를 구현하는 데 유용한 수단이 될 수 있습니다. 아주 간단히 말하면, 변경 사항을 점진적으로 배포하여 다음을 보장하는 것입니다. 커뮤니티는 이에 대응할 수 있는 기회를 제공합니다. 예를 들어, 새로운 MAINCHAIN 계약은 새로운 계약을 배포해야 하도록 제한될 수 있습니다. 활성화하기 최소 30일 전.비상 거버넌스: MAINCHAIN의 악용 가능하거나 악용된 취약점 계약이나 기타 형태의 활성 또는 안전 오류는 치명적인 결과를 방지하기 위해 즉각적인 개입이 필요할 수 있습니다. 우리의 의도는 다중서명을 지원하는 것입니다. 모든 조직의 불법 행위를 방지하기 위한 개입 메커니즘 서명자는 여러 조직에 분산됩니다. 서명자의 일관된 가용성 보장 비상사태 승인을 위해 적절한 명령 체계에 대한 시기적절한 접근 변경 사항을 적용하려면 신중한 운영 계획과 정기적인 검토가 필요합니다. 이것들 과제는 다른 사이버 보안 사고 대응 테스트와 관련된 과제와 유사합니다. 기능 [134], 경계 감소 [223]과 같은 일반적인 문제를 해결하기 위한 유사한 필요성이 있습니다. DONs의 거버넌스는 많은 분산형 시스템의 거버넌스와 다릅니다. 잠재적인 이질성 정도. 각 DON에는 고유한 데이터 소스, 실행 파일, 가동 시간과 같은 서비스 수준 요구 사항 및 사용자가 있을 수 있습니다. Chainlink 네트워크의 거버넌스 메커니즘은 이러한 변화를 수용할 수 있을 만큼 유연해야 합니다. 운영 목표 및 매개변수. 우리는 디자인 아이디어를 적극적으로 탐구하고 있으며, 앞으로 이 주제에 대한 연구를 발표하세요. 7.5 공개 키 인프라 점진적인 분권화로 인해 강력한 식별이 필요해집니다. DON 노드를 포함한 네트워크 참가자. 특히 Chainlink에는 강력한 공개 키 인프라(PKI). PKI는 키를 ID에 바인딩하는 시스템입니다. 에 대한 예를 들어 PKI는 인터넷의 보안 연결(TLS) 시스템을 뒷받침합니다. HTTPS(예: https://www.chainlinklabs.com)을 통해 웹사이트에 연결하고 브라우저에 자물쇠가 나타나면 이는 도메인 소유자의 공개 키가 특히 디지털 서명을 통해 권한에 의해 해당 소유자에게 바인딩되었습니다. 일명 자격증. 최상위 루트 인증 기관이 널리 사용되는 브라우저에 내장되어 있는 CA(인증 기관)의 계층적 시스템은 인증서가 합법적인 도메인 소유자에게만 발급됩니다. 우리는 Chainlink이 결국 분산형 이름 서비스를 사용할 것으로 예상합니다. 처음에는 Ethereum 이름 서비스(ENS) [22]를 PKI의 기반으로 삼았습니다. 다음과 같이 이름에서 알 수 있듯이 ENS는 매핑을 수행하는 도메인 이름 시스템인 DNS와 유사합니다. (사람이 읽을 수 있는) 도메인 이름을 인터넷의 IP 주소로 변환합니다. 그러나 ENS는 대신 사람이 읽을 수 있는 Ethereum 이름을 blockchain 주소에 매핑합니다. 왜냐하면 ENS Ethereum blockchain에서 작동하며 키 손상을 방지하고 네임스페이스는 원칙적으로 이를 관리하는 계약을 변조하는 것만큼 어렵습니다. 및/또는 기본 blockchain. (반대로 DNS는 역사적으로 취약했습니다. 스푸핑, 하이재킹 및 기타 공격에 사용됩니다.) 우리는 Ethereum 메인넷의 ENS에 data.eth를 등록했으며, oracle 데이터 서비스의 ID가 있는 루트 네임스페이스로 설정하고 다른 Chainlink 네트워크 엔터티가 상주합니다. ENS의 도메인은 계층적입니다. 즉, 각 도메인에 참조가 포함될 수 있습니다. 그 아래 다른 이름으로. ENS의 하위 도메인은 구성 및 관리 방법으로 사용될 수 있습니다.신뢰를 위임합니다. data.eth의 주요 역할은 온체인 디렉터리 서비스 역할을 하는 것입니다. 데이터 피드. 전통적으로 oracles의 개발자와 사용자는 오프체인 소스를 사용해 왔습니다. (예: docs.chain.link 또는 data.chain.link와 같은 웹사이트 또는 다음과 같은 소셜 네트워크 Twitter) oracle 데이터 피드 주소(예: ETH-USD 가격)를 게시하고 획득합니다. 피드). data.eth와 같이 매우 신뢰할 수 있는 루트 네임스페이스를 사용하면 대신 eth-usd.data.eth를 smart contract 주소에 매핑하는 것이 가능합니다. ETH-USD 가격 피드에 대한 온체인 oracle 네트워크 수집기. 이것은 누구든지 blockchain를 정보 소스로 참조할 수 있는 보안 경로를 만듭니다. 해당 가격/이름 쌍(ETH-USD)의 데이터 피드입니다. 결과적으로 ENS를 사용하는 방법은 다음과 같습니다. 오프체인 데이터 소스에서는 얻을 수 없는 두 가지 이점을 실현합니다. • 강력한 보안: 도메인에 대한 모든 변경 사항과 업데이트는 불변하게 기록됩니다. 웹사이트의 텍스트 주소와 달리 암호화 방식으로 보호됩니다. 이 두 가지 보안 속성 중 어느 것도 누리지 마십시오. • 자동화된 온체인 전파: 데이터피드의 smart contract 기본 주소를 업데이트하면 종속 스마트에 전파되는 알림이 트리거될 수 있습니다. 예를 들어 종속 계약을 자동으로 업데이트할 수 있습니다. 새 주소.13 그러나 ENS와 같은 네임스페이스는 합법적인 소유권을 자동으로 확인하지 않습니다. 주장된 이름의. 따라서 예를 들어 네임스페이스에 항목이 포함된 경우 ⟨"Acme Oracle Node Co.", 주소⟩, 그런 다음 사용자는 addr이 Acme라는 이름의 청구자에 속한다는 확신을 얻습니다. Oracle Node Co.는 네임스페이스 관리에 대한 추가 메커니즘 없이 그러나 그녀는 그 이름이 합법적으로 법인에 속해 있다는 확신을 얻지 못합니다. 의미 있는 현실 세계의 의미에서 Acme Oracle Node Co.라고 불립니다. 이름 검증, 즉 상응하는 합법적인 실제 개체의 소유권을 보장하는 우리의 접근 방식은 여러 구성 요소에 의존합니다. 오늘은 Chainlink 연구소 Chainlink 네트워크에 대한 CA 역할을 효과적으로 수행합니다. Chainlink 실습은 계속됩니다. 이름을 검증하기 위해 PKI는 두 가지 방법으로 보다 분산된 모델로 발전할 것입니다. • 신뢰 웹 모델: 계층적 PKI의 분산형 대응물을 종종 신뢰 웹이라고 합니다.14 변형은 1990년대부터 제안되었습니다. 예를 들어 [98], 그리고 많은 연구자들은 blockchains가 전 세계적으로 일관된 인증서를 기록함으로써 아이디어(예: [227])의 사용을 용이하게 할 수 있음을 관찰했습니다. 원장. 우리는 엔터티의 신원을 검증하기 위해 이 모델의 변형을 탐색하고 있습니다. Chainlink 네트워크에서 보다 분산된 방식으로. 13A 종속 계약은 선택적으로 수동 검사를 허용하기 위해 미리 결정된 지연을 포함할 수 있습니다. 종속 계약 관리자의 개입. 14PGP [238]에 대해 Phil Zimmermann이 만든 용어입니다.• 검증 데이터에 대한 연결: 오늘날 상당한 양의 oracle 노드 성능 데이터가 온체인에서 볼 수 있으므로 노드 주소에 보관됩니다. 이러한 데이터는 네트워크에 (신뢰할 수 있는) 참여에 대한 역사적 증거를 제공함으로써 PKI의 정체성을 강화하는 것으로 볼 수 있습니다. 추가적으로 도구 DECO 및 Town Crier [160] 활성화 노드를 기반으로 한 분산 ID용 실제 데이터에서 파생된 자격 증명을 축적합니다. 한 가지 예로서, 노드 운영자는 소유를 증명하는 PKI 신원에 자격 증명을 첨부할 수 있습니다. Dun and Bradstreet 등급입니다. 이러한 보완적인 검증 형태는 다음과 같습니다. 네트워크 보안을 보장할 때 staking을 보완하세요. 실제 신원이 확립된 oracle 노드는 지분을 보유한 것으로 간주될 수 있습니다. 그 명성에서 비롯된 시스템에서. (섹션 4.3 및 섹션 9.6.3 참조) Chainlink PKI의 최종 요구 사항은 보안 부트스트래핑입니다. Chainlink 네트워크의 루트 이름, 현재 data.eth 게시(유사하게) 브라우저의 최상위 도메인을 하드와이어링합니다. 즉, Chainlink 사용자는 어떻게 data.eth가 실제로 Chainlink과 연결된 최상위 도메인인지 확인합니다. 프로젝트? Chainlink 네트워크의 이 문제에 대한 해결책은 다각적이며 다음이 포함될 수 있습니다: • 다음을 지정하는 chain.link의 도메인 레코드에 TXT 레코드 [224] 추가 data.eth를 Chainlink 생태계의 루트 도메인으로 사용합니다. (따라서 Chainlink은 루트 ENS 도메인의 유효성을 검사하기 위해 인터넷 도메인에 대한 PKI를 암시적으로 활용합니다.) • Chainlink의 기존 웹사이트(예: https://docs.chain.link. (인터넷 도메인에 대한 PKI의 또 다른 암시적 사용) • 본 백서를 포함한 다양한 문서를 통해 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 커뮤니티. 의도는 DON을 더 광범위하게 사용하는 것입니다. 임의의 실행 파일을 실행하면 나중에 지원될 예정입니다. 이러한 주의가 필요한 한 가지 이유는 최근 플래시 대출 기반 공격이 예를 들어 [127, 189]에 표시되어 있습니다. 마찬가지로 smart contract, 어댑터 및 실행 파일에는 극도의 주의가 필요합니다. DONs의 초기 배포에서는 사전 구축된 템플릿화된 실행 파일 및 어댑터 세트만 포함할 계획입니다. 이를 통해 구성 보안에 대한 연구가 가능해집니다. 공식적인 방법 [46, 170] 및 기타 접근 방식을 사용하여 이러한 기능을 수행합니다. 그럴 것이다 또한 가격 책정을 단순화합니다. 기능 가격 책정은 채택된 접근 방식인 일반화된 측정을 통하지 않고 기능별로 DON 노드별로 설정할 수 있습니다. 예: [156]. 우리는 또한 Chainlink 커뮤니티가 창작에 참여할 것으로 기대합니다. 다양한 어댑터와 실행 파일을 점점 더 많이 결합하는 추가 템플릿 수천 명은 아니더라도 수백 명이 운영할 수 있는 유용한 분산형 서비스 DONs. 또한 이 접근 방식은 상태 팽창(즉, DON의 필요성)을 방지하는 데 도움이 될 수 있습니다. 작업 메모리에 작업할 수 없는 양의 상태를 유지하는 노드입니다. 이 문제는 무허가형 blockchains에서 이미 발생하고 있으며, "상태 비저장"과 같은 접근 방식에 동기를 부여합니다. 클라이언트”(예: [206] 참조). 처리량이 높은 시스템에서는 더욱 심각해질 수 있습니다. DON이 상태 크기에 최적화된 실행 파일만 배포하는 접근 방식입니다. DON이 발전하고 성숙해지며 섹션 7에 설명된 강력한 가드레일, 섹션 9에 설명된 암호화폐 경제 및 평판 기반 보안 메커니즘, DON 사용자에게 높은 수준의 보증을 제공하는 기타 기능을 포함함에 따라 우리는 또한 보다 광범위한 출시와 사용을 촉진하기 위한 프레임워크와 도구를 개발할 것으로 예상됩니다. DONs는 커뮤니티에서 제공합니다. 이상적으로 이러한 도구는 노드 운영자 모음을 활성화합니다. oracle 네트워크로 함께 모여서 무허가 환경에서 자신만의 DON을 시작합니다. 또는 셀프 서비스 방식으로 일방적으로 그렇게 할 수 있음을 의미합니다. 8.2 동적 DON 멤버십 특정 DON을 실행하는 노드 집합은 시간이 지남에 따라 변경될 수 있습니다. 두 가지 접근 방식이 있습니다. O의 동적 멤버십을 통해 SKL의 키 관리에 사용됩니다. 첫 번째는 멤버십 변경 시 노드가 보유한 SKL의 지분을 업데이트하는 것입니다. pkL을 변경하지 않고 유지합니다. [41, 161, 198]에서 탐구된 이 접근법은 장점이 있습니다. 신뢰 당사자가 pkL을 업데이트하도록 요구하지 않습니다.[122]에 도입된 전통적인 공유 재공유 기술은 다음과 같은 간단한 기능을 제공합니다. 그리고 그러한 공유 업데이트를 실현하는 효율적인 방법입니다. 비밀을 전송할 수 있게 해줍니다. 한 세트의 노드 O(1)과 두 번째 노드 사이에서, 아마도 하나의 O(2)와 교차할 수 있습니다. 이에 접근 방식, 각 노드 O(1) 나 전체에서 비밀 공유의 (k(2), n(2)) 비밀 공유를 수행합니다. n(2) = |O(2)|에 대한 O(2)의 노드 그리고 원하는(아마도 새로운) 임계값 k(2). 다양한 VSS(검증 가능한 비밀 공유) 체계 [108]는 다음과 같은 공격자에 대한 보안을 제공할 수 있습니다. 노드를 적극적으로 손상시킵니다. 즉, 프로토콜에 악의적인 동작을 도입합니다. [161]의 기술은 통신 복잡성을 줄이고 다음을 제공하는 동시에 이를 수행하는 것을 목표로 합니다. 암호화 경도 가정의 실패에 대한 탄력성. 두 번째 접근 방식은 원장 키 pkL을 업데이트하는 것입니다. 이는 앞으로의 이점이 있습니다. 보안: pkL의 오래된 공유(예: 이전 위원회 노드)가 손상되지 않습니다. 현재 키가 손상될 수 있습니다. 그러나 pkL 업데이트에는 두 가지 단점이 있습니다. (1) pkL로 암호화된 데이터는 키 새로 고침 중에 다시 암호화되어야 하며 (2) 주요 업데이트는 신뢰 당사자에게 전파되어야 합니다. 우리는 두 가지 접근 방식과 두 가지의 하이브리드화를 모두 탐색할 계획입니다. 8.3 DON 책임 기존 Chainlink oracle 네트워크와 마찬가지로 DONs에는 올바른 노드 동작을 기록, 모니터링 및 시행하는 책임 메커니즘이 포함됩니다. DON은(는) 기존의 많은 무허가 blockchain보다 훨씬 더 많은 데이터 용량, 특히 외부 분산 저장소에 연결할 수 있다는 점을 고려하면 더욱 그렇습니다. 결과적으로 노드의 성능 내역을 자세히 기록할 수 있게 됩니다. 보다 세분화된 책임 메커니즘. 예를 들어, 오프체인 계산은 다음과 같습니다. 자산 가격에는 중간 결과가 전송되기 전에 폐기되는 입력이 포함될 수 있습니다. 체인. DON에는 이러한 중간 결과가 기록될 수 있습니다. 따라서 DON의 개별 노드에 의한 오작동 또는 성능 저하가 해결되거나 처벌될 수 있습니다. DON을 세밀하게 처리합니다. 우리는 구축 방법에 대해서도 추가로 논의했습니다. 시스템 장애의 계약별 영향을 다루는 섹션 7.3의 가드레일. 그러나 DON 자체에 대한 안전 장치 메커니즘을 갖추는 것도 중요합니다. 즉, 체계적이고 잠재적으로 치명적인 DON 오류로부터 보호합니다. 지금 설명하는 것처럼 포크/모호함 및 서비스 수준 계약(SLA) 실패. 포크/모호함: 결함이 있는 노드가 충분히 많으면 DON는 분기할 수 있습니다. 또는 모호하게 표현하여 L에서 두 개의 서로 다른 일관성 없는 블록 또는 블록 시퀀스를 생성합니다. 그러나 DON은 L의 내용에 디지털 서명을 하기 때문에 모호함을 방지 및/또는 처벌하기 위한 메인 체인 MAINCHAIN. DON은 MAINCHAIN의 감사 계약에서 L의 상태를 주기적으로 체크포인트할 수 있습니다. 미래 상태가 체크포인트 상태에서 벗어나면 사용자/감사자는 증거를 제시할 수 있습니다. 감사 계약에 대한 이러한 잘못된 행동. 이러한 증거는 경고를 생성하는 데 사용될 수 있습니다. 또는 계약에서 슬래싱을 통해 DON 노드에 불이익을 줍니다. 이 후자의 접근 방식은 특정 oracle 피드에 대한 것과 유사한 인센티브 설계 문제이며 이를 기반으로 구축할 수 있습니다. 우리의 작업은 섹션 9에 설명되어 있습니다.서비스 수준 계약 시행: DON이 반드시 그런 것은 아닙니다. 무한정 실행되므로 SLA(서비스 수준 계약)를 준수하는 것이 중요합니다. 사용자와 함께. 기본 SLA 시행은 메인 체인에서 가능합니다. 예를 들어, DON 노드는 특정 날짜까지 DON을 유지하거나 서비스 종료에 대한 사전 통지(예: 3개월 전 통지)를 제공하기로 약속할 수 있습니다. 에 대한 계약 MAINCHAIN은 기본적인 암호경제학적 SLA 시행을 제공할 수 있습니다. 예를 들어 SLA 계약은 체크포인트가 다음과 같은 경우 예치된 자금 DON을 삭감할 수 있습니다. 필요한 간격으로 제공되지 않습니다. 사용자는 자금을 입금하고 DON에 이의를 제기할 수 있습니다. 체크포인트가 유효한 블록의 시퀀스를 정확하게 나타내는지 증명하기 위해(어떤 방식으로든) 예를 들어 다음과 유사합니다. [141]). 물론 블록생산은 거래와 동일하지 않습니다. 처리하지만 SLA 계약은 후자를 시행하는 역할도 할 수 있습니다. 예를 들어, 트랜잭션을 mempool에서 가져오고(섹션 5.2 참조) 트랜잭션을 채굴하여 체인에 배치하는 레거시 호환 버전의 FSS입니다. 사용자 다음 거래와 함께 SLA 계약을 제공하여 DON 불법 행위를 입증할 수 있습니다. 채굴되었지만 대상 계약에 의한 처리를 위해 DON에 의해 전송되지 않았습니다. 적절한 시간 간격 내에서.15 보다 세분화된 SLA의 존재를 증명하고 처벌하는 것도 가능합니다. 실행 파일을 사용한 계산 오류를 포함한 실패(예: 메커니즘을 통해) 섹션 6.3에 설명된 올바른 오프체인 상태 트랜잭션 또는 실행 실패를 증명하기 위해 DON에 표시되는 개시자 기반 실행 파일, DON의 데이터를 다음으로 전달하지 못했습니다. 적시에 MAINCHAIN을 수행하는 등의 작업을 수행합니다.
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.
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ụ.
경제학과 암호경제학
Chainlink 네트워크가 분산형 신뢰 모델 내에서 강력한 보안을 달성하려면, 노드가 집합적으로 올바른 동작을 나타내는 것이 중요합니다. 대부분의 경우 정확히 DON 프로토콜에 적용됩니다. 이 섹션에서는 접근 방식에 대해 논의합니다. 경제적 인센티브(일명 암호경제학)를 통해 그러한 행동을 강제하도록 돕는 것입니다. 인센티브. 이러한 인센티브는 명시적 인센티브와 암묵적 인센티브, 실현형이라는 두 가지 범주로 나뉩니다. staking 및 향후 수수료 기회(FFO)를 통해 각각. 스테이킹: 다른 blockchain 시스템과 마찬가지로 Chainlink에 스테이킹하려면 네트워크 참가자(예: oracle 노드)가 참여하고 LINK tokens 형식으로 잠긴 자금을 예치해야 합니다. 이것들 지분 또는 명시적 지분이라고도 하는 자금은 명시적인 인센티브입니다. 그들은 노드 장애 또는 불법 행위 시 몰수될 수 있습니다. blockchain 맥락에서, 이 절차를 흔히 슬래싱이라고 합니다. 그러나 Chainlink의 oracle 노드에 의한 스테이킹은 staking과 근본적으로 다릅니다. 권한이 없는 blockchains에서 validators에 의해. 검증인은 거래를 모호하게 하거나 적대적으로 주문함으로써 잘못된 행동을 할 수 있습니다. 기본 합의 프로토콜 15사용자는 mempool의 트랜잭션을 대체할 수 있으므로 채굴된 트랜잭션과 DON 제출된 트랜잭션 간의 올바른 대응을 보장하기 위해 주의가 필요합니다.하지만 무허가 blockchain은 확실하고 빠른 블록 유효성 검사 규칙과 암호화 프리미티브를 사용하여 validator이 잘못된 블록을 생성하는 것을 방지합니다. 대조적으로, 프로그래밍 방식의 보호로는 부정 행위 oracle 네트워크가 생성되는 것을 방지할 수 없습니다. 잘못된 보고서. 그 이유는 두 가지 시스템 유형 간의 주요 차이점입니다. blockchains의 트랜잭션 유효성 검사는 내부 일관성의 속성인 반면 정확성은 oracle의 blockchain에 대한 보고서는 외부, 즉 오프체인 데이터의 속성입니다. 우리는 Chainlink 네트워크 기반을 위한 예비 staking 메커니즘을 설계했습니다. 외부 데이터를 사용할 수 있는 oracle 노드 간의 대화형 프로토콜에서. 이 메커니즘은 명시적인 보상을 사용하여 올바른 행동에 대한 재정적 인센티브를 생성합니다. 페널티(슬래싱). 메커니즘이 경제적이므로 노드를 방지하도록 설계되었습니다. 금융 자원을 사용하여 노드를 손상시키는 적에 의한 부패 뇌물 수수. (이러한 적은 매우 일반적이며, 예를 들어 협력하는 노드까지 확장됩니다. 집단적인 잘못된 행동에서 가치를 추출합니다.) 우리가 디자인한 Chainlink staking 메커니즘에는 강력하고 새로운 기능이 있습니다. 특징.16 이러한 주요 특징은 초선형 영향(구체적으로는 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 노드에 대한 두 가지 주요 경제적 인센티브를 요약해 보겠습니다. 개발 중인 Chainlink 네트워크의 동작은 다음과 같습니다. • 스테이킹(예치된 지분) 오 명시적 인센티브 • 미래 수수료 기회(FFO) 오 암묵적 인센티브 이 두 가지 형태의 인센티브는 상호보완적입니다. Oracle 노드는 동시에 Chainlink staking 프로토콜에 참여하고, 지속적인 수익원을 즐기세요. 사용자는 지속적인 좋은 행동으로 인해 총체적으로 이익을 얻습니다. 따라서 두 인센티브 모두 oracle 네트워크가 제공하는 암호경제적 보안에 기여합니다. 추가적으로, 두 가지 인센티브는 서로 강화되거나 거래될 수 있습니다. 예를 들어, 실적 내역과 수익원이 없는 새로운 oracle 운영자는 정직한 행동을 보장하기 위해 대량의 LINK를 제공하여 사용자를 유치합니다. 그리고 수수료. 반대로, 길고 상대적으로 결함이 없는 확립된 oracle 연산자 성과 기록은 대규모 사용자 기반에서 상당한 수수료를 부과할 수 있으므로 이에 의존합니다. 암묵적인 인센티브의 형태로 FFO에 더 중점을 두고 있습니다. 일반적으로 여기서 고려하는 접근 방식은 주어진 양의 oracle-네트워크를 목표로 합니다. 합리적으로 Chainlink에서 가능한 최대의 경제적 인센티브를 창출할 수 있는 자원 에이전트(즉, 재정적 효용을 극대화하는 노드)는 정직하게 행동합니다. 다른 것을 넣어 방식으로, 목표는 적이 공격하는 데 필요한 재정 자원을 최대화하는 것입니다. 네트워크가 성공적으로 완료되었습니다. staking 프로토콜을 수학적으로 잘 공식화함으로써 경제적 안보를 정의하고 IIF를 사용하여 우리는 경제 안보의 강도를 측정하는 것을 목표로 합니다. Chainlink의 인센티브를 최대한 정확하게 전달하세요. 의존 계약의 작성자는 그런 다음 oracle 네트워크가 충족하는지 여부를 자신있게 결정할 수 있습니다. 필요한 수준의 암호화폐 보안. 경제 안보의 선순환: 이 섹션에서 논의하는 인센티브인 staking 및 FFO는 보안 강화 이상의 영향을 미칩니다. DONs. 그들은 우리가 경제 안보의 선순환이라고 부르는 것을 유도할 것을 약속합니다. 초선형 staking 영향(및 기타 규모의 경제)으로 인해 운영이 저하됩니다. DON의 보안이 강화됨에 따라 비용이 증가합니다. 비용이 낮아지면 DON에 더 많은 사용자가 유입됩니다.수수료 지불을 강화합니다. 수수료 인상은 계속해서 성장을 촉진합니다. 선순환을 이어가는 네트워크입니다. 우리는 경제 안보의 선순환이 하나의 예일 뿐이라고 믿습니다. 이 섹션의 뒷부분에서 논의할 규모의 경제와 네트워크 효과 등이 있습니다. 섹션 구성: 스테이킹은 주목할만한 기술 및 개념적 과제를 제시합니다. 우리는 새로운 기능을 갖춘 메커니즘을 설계했습니다. 따라서 스테이킹은 이 섹션의 주요 초점은 다음과 같습니다. 섹션 9.1에서 이 문서에 소개된 staking 접근 방식에 대한 개요를 제공하고 섹션 9.2~9.5에서 자세한 논의를 진행합니다. IFF를 소개합니다 섹션 9.6에서. 섹션 9.7에서는 Chainlink 네트워크 인센티브에 대한 요약 보기를 제시합니다. 섹션 9.8에서는 우리가 제안한 staking 접근 방식이 oracle 네트워크에 가져올 수 있는 경제적 보안의 선순환에 대해 논의합니다. 마지막으로 다른 가능성에 대해 간단히 설명하겠습니다. 섹션 9.9에서 Chainlink 네트워크의 성장을 촉진하는 효과가 있습니다. 9.1 스테이킹 개요 위에서 언급한 것처럼 여기서 소개하는 staking 메커니즘 설계에는 oracle 노드 간의 불일치를 해결할 수 있는 대화형 프로토콜이 포함됩니다. 외부 데이터 보고. 스테이킹은 합리적인 oracle 노드의 정직한 행동을 보장하는 것을 목표로 합니다. 따라서 우리는 staking 프로토콜을 공격하는 공격자를 모델링할 수 있습니다. 뇌물 수수: 적의 전략은 재정적 인센티브를 사용하여 oracle 노드를 부패시키는 것입니다. 공격자는 성공적인 변조를 통해 전향적으로 재정적 자원을 확보할 수 있습니다. oracle 보고서를 사용하여 예를 들어 결과 이익을 손상된 노드와 공유하겠다고 제안합니다. 우리는 staking 메커니즘 설계를 동시에 두 가지 야심찬 목표로 삼고 있습니다. 1. 강력한 적에 저항: staking 메커니즘은 보호하기 위해 설계되었습니다. oracle 네트워크는 복잡하고, 뇌물을 제공하는 장래의 뇌물 수수를 포함한 조건부 뇌물 수수 전략 사실 이후에 신원이 확인된 oracles에게(예: 뇌물 제공) 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차 스케일링하여 뇌물 수수를 거의 비현실적으로 만듭니다. 노드가 적당한 양만 스테이킹하는 경우. 이 두 가지 목표를 달성하려면 혁신적인 인센티브 설계 조합이 필요합니다. 그리고 암호화. 주요 아이디어: 우리의 staking 접근 방식은 감시 우선 순위라고 부르는 아이디어에 달려 있습니다. Chainlink oracle 네트워크에서 생성되어 신뢰 계약으로 전송되는 보고서 (예: 자산 가격)은 참여 노드가 제공한 개별 보고서에서 집계됩니다(예: 중앙값을 사용하여). 일반적으로 서비스 수준 계약(SLA) 보고서에 대해 허용 가능한 편차 범위, 즉 노드의 보고서가 얼마나 멀리까지 허용되는지를 지정합니다. 집계 보고서에서 벗어나는 범위와 집계가 어느 정도까지 허용되어야 하는지 실제 값에서 벗어나면 올바른 것으로 간주됩니다. staking 시스템에서 특정 보고 라운드에 대해 각 oracle 노드는 다음과 같은 역할을 할 수 있습니다. 집계 보고서가 부정확하다고 판단되면 경고를 발생시키는 감시자입니다. 각각 보고 라운드에서 각 oracle 노드에는 다음을 결정하는 공개 우선순위가 할당됩니다. 경고(있는 경우)가 처리되는 순서입니다. 우리의 메커니즘은 보상을 목표로 합니다. 이는 경보를 발생시키는 최우선 순위의 감시자가 결함이 있는 노드의 예금을 압수하여 전체 보상을 얻습니다. staking 시스템 설계에는 두 가지 계층, 즉 첫 번째 기본 계층과 두 번째 계층이 포함됩니다. 백스톱 계층. 첫 번째 계층은 n개의 노드 집합인 oracle 네트워크 자체입니다. (단순화를 위해, 우리는 n이 홀수라고 가정합니다.) 대다수의 노드가 잘못된 값을 보고하면 첫 번째 계층은 경고를 발생시키도록 강력한 인센티브를 받습니다. 경고가 발생하면 보고는 그런 다음 네트워크 결정은 네트워크 서비스 수준 계약에서 사용자가 지정할 수 있는 고비용, 최대 신뢰성 시스템인 두 번째 계층으로 승격됩니다. 예를 들어, 강력한 노드로만 구성된 시스템일 수 있습니다. 과거 신뢰도 점수 또는 그보다 훨씬 더 많은 oracle을 가진 점수 첫 번째 계층. 또한 섹션 9.4.3에서 설명한 대로 DECO 또는 Town Crier가 서비스를 제공할 수 있습니다. 두 번째 계층에서 효율적이고 결정적인 판결을 보장하는 데 도움이 되는 강력한 도구입니다. 단순화를 위해 우리는 이 두 번째 계층 시스템이 올바른 보고서에 도달한다고 가정합니다. 가치. 모든 보고서를 생성하기 위해 두 번째 계층에 의존하는 것이 매력적으로 보일 수도 있지만, 우리 설계의 이점은 보안 속성을 지속적으로 달성한다는 것입니다.일반적인 경우에는 운영 비용만 지불하면서 두 번째 계층 시스템을 운영합니다. 1차 시스템. Watchdog 우선 순위는 다음과 같은 방식으로 초선형 staking 영향을 미칩니다. 1차 계층 oracle 네트워크가 잘못된 결과와 다수의 감시 노드를 출력합니다. 경고, staking 인센티브 메커니즘은 우선순위가 가장 높은 감시자에게 다음과 같은 보상을 제공합니다. $dn/2 이상은 (대부분) 오작동하는 노드의 예금에서 인출됩니다. 는 따라서 총 보상은 이 단일 감시자의 손에 집중됩니다. 적이 잠재적인 감시자에게 약속해야 하는 최소값을 결정합니다. 경고하지 않도록 장려하십시오. 우리 메커니즘은 모든 oracle이 우선순위가 높은 감시자가 뇌물을 받은 경우 감시자 역할을 할 수 있는 기회 (그리고 경고하지 않기로 결정한 경우) 따라서 적수는 다음보다 더 많은 뇌물을 제공해야 합니다. 경고가 발생하는 것을 방지하기 위해 모든 노드에 $dn/2. n개의 노드가 있으므로, 성공적인 뇌물 수수를 위해 적의 필수 예산은 $dn2/2 이상입니다. 는 네트워크의 노드 수 n에 대해 2차입니다. 9.2 배경 staking에 대한 우리의 접근 방식은 게임 이론 및 메커니즘 분야의 연구를 바탕으로 합니다. 디자인(MD)(교과서 참조는 [177] 참조). 게임이론은 수학적으로 전략적 상호작용에 대한 공식화된 연구. 이런 맥락에서 게임은 그러한 모델이다. 일반적으로 현실 세계에서 사용 가능한 일련의 작업을 체계화하는 상호 작용 플레이어라고 하는 게임 참가자. 게임은 또한 획득한 보상을 지정합니다. 개별 플레이어에 의한 보상 - 플레이어가 선택한 행동과 결과에 따라 달라지는 보상 다른 플레이어의 행동. 아마도 게임에서 연구된 게임의 가장 잘 알려진 예일 것입니다. 이론은 죄수의 딜레마 [178]입니다. 게임 이론가들은 일반적으로 이해하는 것을 목표로 합니다. 주어진 게임에서 표현되는 평형 또는 평형(있는 경우). 균형은 어느 누구도 더 높은 점수를 얻을 수 없는 일련의 전략(각 플레이어당 하나씩) 일방적으로 전략에서 벗어나는 결과를 초래합니다. 한편, 메커니즘 디자인은 인센티브를 디자인하는 과학입니다. 상호 작용(및 관련 게임)의 균형에는 몇 가지 바람직한 속성이 있습니다. MD는 게임 이론의 반대라고 볼 수 있습니다: 게임의 정식 질문 이론은 "인센티브와 모델이 주어지면 균형은 어떻게 될까요?"입니다. MD에서는 대신 질문은 "어떤 인센티브가 바람직한 균형을 이루는 게임을 만들 것인가?"입니다. 메커니즘 설계자의 일반적인 목표는 '인센티브 호환' 메커니즘을 만드는 것입니다. 즉, 메커니즘 참가자(예: 경매 또는 기타 정보)가 유도 시스템 [228])은 어떤 문제(예: 어떻게 그들은 특정 품목을 매우 중요하게 생각합니다). Vickrey(2차 가격) 경매는 아마도 참가자가 봉인된 입찰을 제출하는 가장 잘 알려진 인센티브 호환 메커니즘 품목에 대해 가장 높은 입찰자가 품목을 획득하지만 두 번째로 높은 가격을 지불합니다. [214]. 암호경제학은 암호학을 활용하는 도메인별 MD 형태입니다. 분산형 시스템 내에서 바람직한 균형을 만드는 기술. 뇌물수수와 공모는 MD 분야 전반에 걸쳐 심각한 문제를 야기합니다. 거의 모든 메커니즘은 담합(부차적 계약으로 정의됨)이 있는 경우 중단됩니다.메커니즘에 참여하는 당사자 사이를 연결합니다[125, 130]. 외부 당사자가 게임에 새로운 인센티브를 도입하는 뇌물수수는 더욱 심각한 문제를 야기합니다. 공모보다; 담합은 게임 간 뇌물수수의 특수한 경우로 볼 수 있다. 참가자. 블록체인 시스템은 종종 금전적(암호화폐 기반) 보상을 제공하는 게임으로 개념화될 수 있습니다. 간단한 예는 작업 증명 채굴입니다. 채굴자는 행동 공간을 갖습니다. 블록을 채굴할 hash비율을 선택할 수 있습니다. 채굴의 보상은 보장된 음의 보상(전기 및 장비 비용)에 확률론적 보상을 더한 것입니다. 다른 활성 채굴자 수에 따라 달라지는 긍정적인 보상(채굴 보조금) [106, 172] 및 거래 수수료. SchellingCoin [68]과 같은 크라우드소싱 oracle은 또 다른 예입니다. 작업 공간은 oracle이 보낼 수 있는 가능한 보고서 세트입니다. 지불은 oracle 메커니즘에 의해 지정된 보상입니다. 예를 들어 지불은 달라질 수 있습니다. oracle의 보고서가 다른 보고서의 중앙값에 얼마나 가까운지에 대한 정보입니다[26, 68, 119, 185]. 블록체인 게임은 공모 및 뇌물 공격의 기회를 제공합니다. 실제로, smart contracts는 이러한 공격을 용이하게 할 수도 있습니다[96, 165]. 아마도 가장 잘 알려진 크라우드소싱된 oracles에 대한 뇌물 수수 공격은 p-plus-epsilon 공격 [67]입니다. 이 공격 플레이어가 부울 값 보고서(즉, 거짓 또는 참)를 제출하고 해당 내용에 동의할 경우 p로 보상받는 SchellingCoin과 유사한 메커니즘의 맥락에서 발생합니다. 다수 제출. p-plus-epsilon 공격에서 공격자는 다음과 같이 확실하게 약속합니다. 예를 들어, 다수의 제출이 사실인 경우에만 거짓 투표에 대해 사용자에게 $p + ϵ를 지불합니다. 그 결과 모든 플레이어가 허위 보고를 하도록 장려되는 균형이 이루어졌습니다. 다른 플레이어가 무엇을 하든 상관없습니다. 결과적으로 뇌물은 노드를 유도할 수 있습니다. 약속된 뇌물을 통해 실제로 뇌물을 주지 않고 허위신고를 하게 됩니다(!). 그러나 oracle, 특히 크라우드소싱되지 않은 oracle의 맥락에서 다른 뇌물 수수 전략을 탐색하는 것은 상당히 약한 적에게만 국한되었습니다. 모델. 예를 들어, PoW 환경에서 연구자들은 결과에 따른 결과를 연구했습니다. 뇌물, 즉 대상 메시지가 성공적으로 검열되고 검열되지 않은 경우에만 뇌물이 지급됩니다. 개별 광부의 행동과 관계없이 블록에 나타납니다[96, 165]. 이 경우 그러나 p-plus-epsilon 공격 외에 우리는 oracles의 작업만 알고 있습니다. 뇌물수수자가 조건부로 뇌물을 보내는 엄격하게 제한된 뇌물수수 모델 결과가 아닌 개별 플레이어의 행동에 따라 결정됩니다. 여기서 우리는 인센티브를 유지하는 정보 추출 메커니즘의 설계를 스케치합니다. 다음 하위 섹션에서 설명하는 것처럼 강력한 적대적 모델에서도 호환됩니다. 9.3 모델링 가정 이 하위 섹션에서는 플레이어의 행동과 능력을 모델링하는 방법을 설명합니다. 우리 시스템, 특히 첫 번째 계층 oracle 노드, 두 번째 계층의 노드(판정) 레이어와 적.9.3.1 1차 인센티브 모델: Rational Actors 많은 blockchain 시스템은 몇 가지 정직한 정보를 가정하여 보안에 의존합니다. 참여 노드. 노드는 프로토콜을 따르면 정직하다고 정의됩니다. 그렇게 하는 것이 재정적으로 이익이 되지 않는 경우. 일반적으로 작업 증명 시스템 솔직히 말해서 대부분의 hash 권한이 필요합니다. 지분 증명 시스템은 일반적으로 솔직히 말해서 모든 참여 지분의 2/3 이상이 필요하며 심지어 다음과 같은 레이어 2 시스템도 필요합니다. Arbitrum [141]에는 최소한 한 명의 정직한 참가자가 필요합니다. staking 메커니즘을 모델링할 때 우리는 훨씬 약한 가정을 합니다. (될 명확하고 약한 가정은 더 강력한 보안 특성을 의미하므로 바람직합니다.) 우리는 적이 손상, 즉 통제, 일부(소수)를 손상했다고 가정합니다. 첫 번째 계층 oracle 노드의 비율입니다. 우리는 정직한 에이전트가 아닌 나머지 노드를 모델링합니다. 그러나 합리적 기대효용 극대화자로서. 이러한 노드는 전적으로 이기적인 재정적 인센티브에 따라 행동하며 예상되는 재정적 결과를 가져오는 행동을 선택합니다. 이득. 예를 들어, 노드가 다음으로 인한 보상보다 더 큰 뇌물을 제공받는 경우 정직하게 행동하면 뇌물을 받을 것입니다. 적대적 노드에 대한 참고 사항: 일반적인 신뢰 모델링에 따르면 분산형 시스템에서는 모든 노드가 합리적이라고 가정합니다. 즉, 최대화를 추구합니다. 악의적인 적에 의해 통제되는 것이 아니라 순수익입니다. 그러나 우리의 주장은— 특히 초선형 또는 2차 staking 영향 - 점근적으로 제공됨 적대적으로 제어되는 노드 세트는 최대 (1/2 −c)n입니다. 일부 긍정적인 경우 상수 다. 9.3.2 2차 판단 모델: 가정에 의한 정확성 보안을 달성하는 데 도움이 되는 staking 메커니즘의 중요한 기능은 합리적인 노드에 대한 두 번째 계층 시스템입니다. 제안된 staking 메커니즘에서 모든 oracle은 다음을 나타내는 경고를 발생시킬 수 있습니다. 메커니즘의 출력이 올바르지 않다고 생각합니다. 경고로 인해 신뢰도가 높아집니다. 두 번째 계층 시스템을 활성화하고 올바른 결과를 보고합니다. 따라서 핵심 모델링 우리의 접근 방식에 대한 요구 사항은 올바른 판결, 즉 2차 시스템. 우리의 staking 모델은 부패할 수 없고 최대한 신뢰할 수 있는 정보 소스 역할을 하는 2차 계층 시스템을 가정합니다. 이러한 시스템은 비용이 많이 들고 속도가 느릴 수 있습니다. 일반적인 경우에 사용하기에는 부적절합니다. 그러나 평형의 경우, 즉 첫 번째 계층 시스템이 올바르게 작동하면 두 번째 계층 시스템이 호출되지 않습니다. 대신, 그 존재는 다음을 제공함으로써 전체 oracle 시스템의 보안을 강화합니다. 높은 보증 백스톱. 신뢰도가 높고 비용이 높은 판결 레이어의 사용은 항소 프로세스와 유사합니다. 대부분의 사법 시스템의 핵심입니다. oracle 디자인에서도 이미 흔히 볼 수 있는 현상입니다. 시스템(예: [119, 185]). 우리는 두 번째 계층의 실현에 대한 접근 방식을 간략하게 논의합니다. 섹션 9.4.3의 메커니즘에서.우리의 staking 프로토콜은 oracle 노드의 올바른 보고를 시행하기 위한 신뢰할 수 있는 위협으로 두 번째 계층 시스템의 올바른 판결 가정을 사용합니다. 프로토콜 다음으로 식별되는 보고서를 생성하는 oracle 노드 지분의 일부 또는 전부를 압수합니다. 두 번째 계층 시스템이 잘못된 것으로 간주됩니다. 따라서 Oracle 노드는 오작동을 방지합니다. 그에 따른 금전적 처벌을 받습니다. 이 접근 방식은 다음에서 사용되는 방식과 유사합니다. 낙관적인 rollups(예: [141, 10]) 9.3.3 적대적 모델 우리의 staking 메커니즘은 광범위하고 잘 정의된 적군에 대해 보안을 달성하면서 진실한 정보를 도출하도록 설계되었습니다. 이전 작품에 비해 개선되었으며, 이는 명시적인 적대적 모델을 생략하거나 위에서 논의한 p-plus-epsilon 적과 같은 좁은 하위 클래스의 적에 초점을 맞춥니다. 우리의 목표는 staking을 디자인하는 것입니다. 모든 종류의 공격자에 대해 공식적으로 입증된 보안을 갖춘 메커니즘 실무에서 접하게 됩니다. 우리는 상대방이 다음과 같이 고정된(매개변수화 가능한) 예산을 갖고 있다고 모델링합니다. $B. 적은 oracle와 개별적으로 비밀리에 통신할 수 있습니다. 네트워크를 통해 개인에게 비밀리에 뇌물 지급을 보장할 수 있습니다. 메커니즘의 공개적으로 관찰 가능한 결과에 따라 달라집니다. 결과 결정 뇌물에는 예를 들어 oracle에서 보고한 값, 공개 메시지 등이 포함될 수 있습니다. oracle에 의해 메커니즘(예: 경고)으로 전송된 값은 다른 oracles 및 메커니즘에 의해 출력되는 값입니다. 무제한의 능력을 갖춘 공격자로부터 보호할 수 있는 메커니즘은 없습니다. 따라서 일부 동작은 비현실적이거나 범위를 벗어난 것으로 간주됩니다. 우리는 공격자를 가정합니다 표준 암호화 기본 형식을 깨뜨릴 수 없으며 위에서 언급한 것처럼 고정되어 있습니다(만약 잠재적으로 큰 규모) 예산 $B. 또한 적이 통제하지 못한다고 가정합니다. oracle 네트워크에서의 통신은 특히 실질적으로 지연될 수 없습니다. 첫 번째 계층 및/또는 두 번째 계층 노드 간의 트래픽. (상대가 그러한 통신을 관찰할 수 있는지 여부는 아래에서 설명하는 것처럼 특정 메커니즘에 따라 다릅니다.) 그러나 위에서 언급한 바와 같이 비공식적으로는 적이 다음과 같이 할 수 있다고 가정합니다. (1) 부패 oracle 노드의 일부(일부 상수 c에 대한 (1/2 −c)-분수), 즉 완전히 제어 (2) 지불 조건을 보장하여 원하는 노드에 뇌물을 제공합니다. 위에서 설명한 대로 적이 지정한 결과에 따라 결정됩니다. 우리는 적의 전체 공격에 대한 공식적인 모델이나 완전한 분류를 제공하지 않습니다. 본 백서에 나와 있는 다양한 뇌물 수수 능력에 대한 예는 다음과 같습니다. 우리 모델에 포함되는 뇌물 수수. 단순화를 위해 oracles가 부울을 방출한다고 가정합니다. 정확한 값(w.l.o.g.)이 참이고 최종 결과가 다음과 같이 계산되는 보고서입니다. smart contract 소비에 의해 사용되는 이러한 보고서의 집합입니다. 뇌물을 준 사람의 목표는 최종 결과가 부정확해지는 것, 즉 거짓이 되는 것입니다. • 무조건적인 뇌물수수: 뇌물수수자는 허위 보고를 하는 모든 oracle에게 $b 뇌물을 제공합니다. • 확률적 뇌물수수: 뇌물수수자는 임의의 oracle에게 q 확률로 $b 뇌물을 제공합니다. 거짓으로 보고하는 것입니다.• 거짓 결과 조건부 뇌물: 뇌물은 최종 결과가 거짓인 경우 거짓을 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. • 비경고 조건 뇌물수수: 뇌물수수자는 보고하는 모든 oracle에게 뇌물 $b를 제공합니다. 경고가 발생하지 않는 한 false입니다. • p-plus-epsilon 뇌물 수수: 뇌물 수수는 다음과 같이 허위 보고를 하는 모든 oracle에게 뇌물 $b를 제공합니다. oracles의 대다수가 거짓을 보고하지 않는 한. • 잠재적 뇌물 수수: 뇌물 수수자는 oracle을 선택한 사람에게 미리 $b의 뇌물을 제공합니다. 무작위 역할에 대해 거짓으로 보고합니다. 우리가 제안한 staking 프로토콜에서는 모든 노드는 잠재적인 감시자 역할을 하며, 우리는 무작위화를 보여줄 수 있습니다 감시 우선 순위는 잠재적인 뇌물 수수에 적합하지 않습니다. 많은 작업 증명, proof-of-stake 및 허가된 시스템은 잠재적으로 취약합니다. 그러나 뇌물수수는 적의 입장에서 이를 고려하는 것이 중요함을 보여줍니다. 모델을 만들고 staking 프로토콜이 이에 대한 탄력성을 갖도록 보장합니다. 부록 E를 참조하세요. 자세한 내용은 9.3.4 암호경제학적 보안은 어느 정도면 충분합니까? 합리적인 공격자는 이익을 얻을 수 있는 경우에만 시스템을 공격하는 데 돈을 지출합니다. 지출보다 더 크다. 따라서 우리의 적대적 모델과 제안된 staking에 대해 메커니즘에서 $B는 적이 얻을 수 있는 잠재적 이익의 척도로 볼 수 있습니다. oracle 네트워크를 손상시키고 이를 유발하여 의존하는 smart contract에서 추출합니다. 잘못된 보고서 또는 보고서 세트를 생성합니다. oracle 네트워크 여부를 결정할 때 목적에 맞는 충분한 수준의 암호경제적 보안을 제공하는 경우, 사용자는 다음을 수행해야 합니다. 이러한 관점에서 네트워크를 평가하십시오. 실제 상황에서 그럴듯한 적의 경우 $B는 일반적으로 smart contracts에 의존하는 총 자산보다 훨씬 작습니다. 대부분의 경우, 공격자가 이러한 자산을 전체적으로 추출하는 것은 불가능합니다. 9.4 스테이킹 메커니즘: 스케치 여기서 우리는 staking 메커니즘의 주요 아이디어와 일반 구조를 제시합니다. 현재 고려 중입니다. 프레젠테이션의 편의를 위해 간단하지만 느린 방법을 설명합니다. (다중) 프로토콜. 그러나 우리는 이 계획이 상당히 실용적. 메커니즘이 제공하는 경제적 보장, 즉 결함이 있는 노드에 대한 처벌 및 그에 따른 인센티브를 고려하면 많은 사용자가 기꺼이 다음을 수행할 수 있습니다. 보고서를 낙관적으로 받아들입니다. 즉, 해당 사용자는 신고 이전에 신고를 수락할 수 있습니다. 두 번째 계층의 잠재적인 판결. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자는 프로토콜이 나올 때까지 기다리도록 선택할 수 있습니다. 즉, 두 번째 계층으로의 잠재적인 에스컬레이션이 발생할 때까지 실행이 종료됩니다. 이, 그러나 보고서 확인 시간이 상당히 느려질 수 있습니다. 그러므로 우리는 간략하게그림 15: 경고가 포함된 staking 체계의 도식. 이 예에서는 1⃝a 다수 의 노드가 손상되거나 뇌물을 받고 올바른 값이 아닌 잘못된 값 ~r을 방출합니다. 보고서 값 r. 감시 노드 2⃝는 2차 위원회에 경고를 보냅니다. 3⃝은 올바른 보고 값 r을 결정하고 내보내며, 그 결과 노드가 손상됩니다. 각 $d는 워치독 노드 4⃝에 예치금을 몰수합니다. 다소 더 많은 경우 더 빠른(단일 라운드) 결과를 가져오는 몇 가지 최적화에 대한 개요를 설명합니다. 섹션 9.5의 복잡한 설계. staking 메커니즘의 첫 번째 계층은 기본 oracle로 구성됩니다. 네트워크 자체. 위에서 설명한 것처럼 우리 메커니즘의 주요 구조는 각 라운드마다 다음과 같습니다. 각 노드는 우선 순위에 따라 "감시자" 역할을 할 수 있습니다. 메커니즘이 올바른 출력이 아닌 잘못된 출력 ~r에 도달하면 경고를 발생시킵니다. 하나의 r. 이 경고는 올바른 결과에 도달한다고 가정하는 두 번째 계층 해결 방법을 발생시킵니다. 보고. 잘못된 보고를 한 노드는 지분이 있다는 의미에서 처벌됩니다. 감시견에게 베고 수여했습니다. 이 기본 구조는 oracle 시스템에서 일반적입니다. 예를 들어 [119, 185]와 같습니다. 위에서 간략히 언급한 우리 설계의 핵심 혁신은 모든 노드가 잠재적인 감시자 순서에 따라 뚜렷한 우선순위가 할당됩니다. 즉 감시견이다. 우선순위에 따라 경고할 기회가 주어집니다. 노드에 경고를 발생시키는 것이 가장 높은 우선순위이며 모든 오작동에 대해 $d의 삭감된 예치금을 받습니다. 잘못된 보고는 다음을 의미하므로 총 \(dn/2 = \)d × n/2보다 많은 노드 대부분의 불량 노드. 결과적으로, 적은 최소한 이 보상을 지불해야 합니다. 임의의 노드에 뇌물을 줍니다. 따라서 대다수의 노드에 뇌물을 제공하려면 공격자는 다음과 같은 비용을 지불해야 합니다. 즉, 엄밀히 말하면 $dn2/2보다 많은 대규모 뇌물을 노드에 제공합니다. 그림 15에서는 경고 및 감시 에스컬레이션이 어떻게 작동하는지 개략적으로 보여줍니다.9.4.1 추가 메커니즘 세부정보 이제 우리가 더 자세히 설명하는 뇌물 방지 시스템은 다음과 같은 단순화된 개요입니다. 우리가 건설하려는 2층 구조. 우리의 초점은 대부분 설명하는 것입니다. 첫 번째 계층 네트워크(이하 맥락에서 명확한 경우 간단히 "네트워크") 인센티브 메커니즘과 두 번째 계층으로의 에스컬레이션 절차를 설명합니다. 다음을 담당하는 n개의 oracle 노드로 구성된 Chainlink 네트워크를 생각해 보세요. 정기적으로(예: 1분에 한 번) 부울 값(예: 시장이 BTC의 시가총액이 ETH의 시가총액을 초과합니다. staking 메커니즘의 일부로 노드는 두 가지 보증금을 제공해야 합니다. 보증금 $d는 동의하지 않을 경우 삭감될 수 있습니다. 다수 및 감시 예치금 $dw에 결함이 있는 경우 삭감될 수 있음 에스컬레이션. 우리는 노드가 다른 노드의 제출물을 복사할 수 없다고 가정합니다. 섹션 5.3에서 논의된 커밋-공개 체계를 통해. 각 라운드에서 노드가 먼저 보고서를 커밋하고 모든 노드가 커밋되면(또는 제한 시간이 만료되면) 노드는 보고서를 공개합니다. 생성될 각 보고서에 대해 모든 노드에는 무작위로 선택된 1과 n 사이의 감시 우선순위가 부여되며, 1이 최고 우선순위입니다. 이 우선순위를 사용하면 한 감시자의 손에 보상이 집중됩니다. 모든 신고가 공개된 후, 경고 단계가 이어집니다. n(동기) 라운드의 시퀀스에 걸쳐 노드는 우선 순위는 i 라운드에서 경고할 기회가 있습니다. 노드가 공개된 후 메커니즘에 대한 가능한 결과를 고려해 보겠습니다. 그들의 보고서. 다시 이진 보고서를 가정하고 올바른 값이 true이고 잘못된 것은 거짓입니다. 또한 첫 번째 계층 메커니즘이 다음을 출력한다고 가정합니다. 최종 보고서 r로서 노드에 의해 출력된 다수의 값. 메커니즘에는 세 가지 가능한 결과가 있습니다. • 완전한 합의: 최선의 경우 노드는 완전한 합의에 있습니다. 모든 노드는 사용 가능하며 동일한 값 r에 대한 보고를 시기적절하게 제공했습니다(둘 중 하나). 또는 거짓). 이 경우 네트워크는 r을 의존 계약으로 전달하기만 하면 됩니다. 각 노드에 라운드당 고정 지불금 $p를 지급합니다. 이는 훨씬 작은 금액입니다. $d보다. • 부분적 동의: 일부 노드가 오프라인이거나 어떤 값이 올바른지에 대해 의견 차이가 있을 수 있지만 대부분의 노드는 true를 보고하고 소수의 보고가 거짓입니다. 이 경우도 간단합니다. 다수의 가치 (true)가 계산되어 올바른 보고서 r이 생성됩니다. r을 보고한 모든 노드는 잘못 신고한 oracles가 예치금을 가지고 있는 동안 $p로 보상을 받습니다. 예를 들어 $10p 정도 인하되었습니다. • 경고: 감시자가 네트워크의 출력이 잘못되었다고 판단하는 경우, 이는 공개적으로 경고를 트리거하여 메커니즘을 2차 계층 네트워크로 확대합니다. 그러면 두 가지 결과가 나올 수 있습니다. – 올바른 경고: 두 번째 계층 네트워크에서그림 16: 집중된 경고 보상을 통해 뇌물 수수 비용을 증폭시킵니다. 뇌물 공격자는 경고를 통해 얻을 수 있는 보상보다 더 많은 것을 각 노드에 뇌물을 주어야 합니다. (빨간색 막대로 표시됨) 경고 보상이 공유되는 경우 이 보상은 상대적일 수 있습니다. 작다. 집중된 경고 보상은 단일 노드가 얻을 수 있는 보상을 증가시킵니다. (높은 빨간색 막대)를 얻습니다. 결과적으로 상대방이 실행 가능한 뇌물에 대해 지불한 총 금액은 다음과 같습니다. (회색 영역)은 공유된 알림 보상보다 집중된 알림 보상이 훨씬 더 큽니다. 첫 번째 계층 네트워크가 올바르지 않아 경고하는 감시 노드가 보상을 받습니다. 모두 삭감된 예금으로 구성되므로 $dn/2 이상입니다. – 잘못된 경고: 두 번째 계층과 첫 번째 계층 oracle이 동의하는 경우 에스컬레이션은 결함이 있는 것으로 간주되고 경고 노드는 $dw 보증금을 잃습니다. 보고서가 긍정적으로 받아들여지는 경우 감시 경보는 다음을 유발하지 않습니다. 의존 계약 실행의 모든 변경. 기다리도록 설계된 계약의 경우 2위 위원회 중재 가능성, 감시단 경고는 늦어졌지만 계약 실행을 동결하지 마십시오. 계약을 통해 지정하는 것도 가능합니다. 판정 기간 동안 장애 조치 DON. 9.4.2 2차 스테이킹 영향 엄격한 노드 우선순위와 결합하여 모든 노드가 감시 역할을 하는 기능 집중된 보상을 보장하여 메커니즘이 2차 staking을 달성할 수 있도록 합니다. 섹션 9.3.3에 설명된 각 종류의 뇌물 공격자에 대한 영향. 이것을 기억하십시오 이는 우리 설정에서 각각 보증금이 있는 n개의 노드가 있는 네트워크의 경우를 의미합니다. $d, 성공적인 뇌물 제공자(위의 종류 중 하나)는 다음보다 더 큰 예산을 가져야 합니다. $dn2/2. 정확하게 말하면 뇌물수수자는 최소한 (n+1)/2개의 노드를 부패시켜야 합니다. n 노드의 대다수를 손상시킵니다(가정에 따라 홀수 n의 경우). 따라서 감시자는 다음을 수행합니다. $d(n + 1)/2의 보상을 얻습니다. 따라서 뇌물 제공자는 모든 사람에게 이 금액을 지불해야 합니다.노드가 감시자 역할을 하지 않도록 합니다. 우리는 다음과 같은 사실을 공식적으로 보여주기 위해 노력하고 있습니다. 뇌물 제공자는 최대 $d(n2 + n)/2의 예산을 가지며, 하위 게임 완전 균형이 됩니다. 뇌물수수자와 oracles 사이의 게임, 즉 균형 게임이 진행되는 동안 어느 시점에서든 뇌물을 준 사람은 뇌물을 발행해서는 안 되며, 각 oracle의 진정한 가치를 정직하게 보고합니다. 우리는 성공적인 뇌물 제공을 위해서는 다음과 같은 방법이 필요할 수 있다는 점을 위에서 설명했습니다. 노드 예치금의 합계보다 예산이 훨씬 더 많습니다. 이것을 설명하기 위해 직관적인 결과, 그림 16은 집중된 경고 보상의 영향을 그래픽으로 보여줍니다. 거기에서 볼 수 있듯이, 감시자 경보에 대한 보상, 즉 뇌물 예치금이 지급된다면 false를 보고하는 노드) - 모든 잠재적 경고로 분할되었으며, 개별 경고 노드는 상대적으로 작을 것이라고 예상할 수 있습니다. $d. $d보다 큰 지불금이 있을 가능성이 낮다는 것을 알고 있는 뇌물 제공자는 다음과 같은 방법을 사용할 수 있습니다. n개의 노드 각각에 다음보다 약간 더 많은 뇌물을 제공하는 거짓 결과 조건부 뇌물 $d + ϵ. 반직관적으로, 그림 16은 보상을 광범위하게 분배하는 시스템을 보여줍니다. 경고를 보내는 노드 중 보상을 집중시키는 노드보다 훨씬 약합니다. 하나의 감시견의 손. 예시 매개변수: n = 100개의 노드가 있는 (1차 계층) 네트워크를 생각해 보세요. \(d = \)20K를 입금합니다. 이 네트워크에는 총 200만 달러가 예치되어 있지만 예산 \(100M = \)dn2/2로 뇌물로부터 보호받을 수 있습니다. 수의 증가 oracles는 물론 $d를 늘리는 것보다 더 효과적이며 극적인 효과를 가질 수 있습니다. n = 300개 노드와 예치금 \(d = \)20K를 가진 네트워크는 다음과 같은 위험으로부터 보호됩니다. 최대 9억 달러의 예산으로 뇌물을 제공합니다. staking 시스템은 많은 경우에 다음을 나타내는 smart contract을 보호할 수 있습니다. 제공되는 뇌물수수 방지 수준보다 더 많은 가치를 갖습니다. 그 이유는 상대방이 이러한 계약을 공격하면 많은 경우 전체 가치를 추출할 수 없습니다. 예를 들어, 10억 달러의 가치를 보장하는 Chainlink 기반 계약에는 담보만 필요할 수 있습니다. 그러한 적이 실현 가능하게 이익을 추출할 수 있기 때문에 1억 달러의 자원을 가진 뇌물 수수자 계약금액의 10%에 불과하다. 참고: 네트워크의 가치가 2차적으로 증가할 수 있다는 생각은 다음과 같이 표현됩니다. 잘 알려진 Metcalfe의 법칙[167, 235]은 네트워크의 가치가 연결된 엔터티 수가 2차적으로 증가합니다. 그러나 Metcalfe의 법칙은 잠재적인 쌍별 네트워크 연결 수의 증가로 인해 발생합니다. 이는 인센티브에 기본이 되는 2차 staking 영향과는 다른 현상입니다. 메커니즘. 9.4.3 Second Tier 실현 두 가지 운영 기능으로 신뢰성이 높은 두 번째 계층의 실현을 촉진합니다. (1) 2단계 판결은 oracle 네트워크에서는 드문 경우이므로 다음과 같은 일이 발생할 수 있습니다. 첫 번째 계층의 일반 운영보다 훨씬 더 많은 비용이 듭니다. (2) 가정낙관적으로 받아들여진 보고서 또는 실행이 중재를 기다릴 수 있는 계약 두 번째 계층은 실시간으로 실행될 필요가 없습니다. 이러한 기능으로 인해 다양한 결과가 발생합니다. 특정 DON의 요구 사항을 충족하기 위한 두 번째 계층의 구성 옵션입니다. 접근 방식의 예로서, 두 번째 계층 위원회는 다음과 같은 노드로 구성될 수 있습니다. Chainlink에서 가장 오래 서비스되고 가장 안정적인 노드의 DON(즉, 첫 번째 계층) 네트워크. 상당한 관련 운영 경험 외에도 운영자는 그러한 노드 중 FFO에는 욕구를 유발하는 상당한 암시적 인센티브가 있습니다. Chainlink 네트워크의 신뢰성이 높게 유지되도록 합니다. 그들은 또한 공개적으로 신뢰성에 대한 투명성을 제공하는 사용 가능한 성능 기록입니다. 두 번째 계층 노드는 첫 번째 계층 네트워크에 참여할 필요가 없으며 주목할 가치가 있습니다. 여러 1차 네트워크 전반에 걸쳐 결함을 판정할 수 있습니다. 주어진 DON의 노드는 다음과 같은 n' 집합을 미리 지정하고 공개적으로 커밋할 수 있습니다. 노드는 해당 DON에 대한 2차 위원회를 구성합니다. 또한 DON 노드는 2차 투표 수를 결정하는 매개변수 k′ ≤n′을 게시합니다. 첫 번째 계층 노드에 페널티를 적용하는 데 필요합니다. 특정 보고서에 대해 경고가 생성되면 두 번째 계층의 구성원은 각 계층이 제공한 값의 정확성에 대해 투표합니다. 첫 번째 계층 노드 중 하나입니다. k′ 부정 투표를 받은 첫 번째 계층 노드는 해당 노드를 상실합니다. 워치독 노드에 예치합니다. 재판이 드물고, 장기집행 기회가 드물기 때문이다. 위에서 언급했듯이 첫 번째 계층과 달리 두 번째 계층의 노드는 다음을 수행할 수 있습니다. 1. 판결 수행에 대해 높은 보상을 받습니다. 2. 첫 번째 데이터 소스에서 사용하는 다양한 세트를 넘어서는 추가 데이터 소스를 활용합니다. 3. 수동 및/또는 전문가 검사 및 개입에 의존합니다. 예를 들어 식별하고 소스 데이터의 오류를 조정하고 정직한 노드 중계를 구별합니다. 잘못된 데이터와 오작동하는 노드. 우리는 두 번째 계층 노드 선택과 판결을 관리하는 정책에 대해 방금 설명한 접근 방식이 대규모 노드 내의 한 지점일 뿐이라는 점을 강조합니다. 두 번째 계층의 가능한 실현을 위한 설계 공간. 우리의 인센티브 메커니즘은 다음과 같습니다. 두 번째 계층을 구현하는 방법에 대한 완전한 유연성. 따라서 개별 DON은(는) 특정 요구 사항을 충족하는 두 번째 계층에 대한 규칙을 구성하고 설정합니다. 참여 노드와 사용자의 기대. 심사 도구로서의 DECO 및 Town Crier: 2층에서는 꼭 필요합니다 우리 메커니즘에서는 적대적인 첫 번째 계층 노드를 구별할 수 있습니다. 의도적으로 잘못된 보고서를 생성하고 의도치 않게 정직한 1차 노드를 생성합니다. 소스에서 잘못된 데이터를 중계합니다. 그래야만 두 번째 계층에서 구현할 수 있습니다. 우리 메커니즘의 목표인 부정 행위를 방지하기 위해 삭감합니다. DECO와 타운 크라이어 두 번째 계층 노드가 이러한 중요한 구별을 할 수 있도록 하는 강력한 도구입니다. 안정적으로.두 번째 계층 노드는 경우에 따라 사용된 데이터 소스를 직접 쿼리할 수 있습니다. 잘못된 보고가 있는지 확인하려면 첫 번째 계층 노드를 사용하거나 ADO 섹션 7.1을 사용하세요. 잘못된 데이터 소스로 인해 발생했습니다. 그러나 다른 경우에는 두 번째 계층 노드가 부족할 수 있습니다. 첫 번째 계층 노드의 데이터 소스에 직접 액세스합니다. 이런 경우에는 올바른 판단이 필요합니다. 실행 불가능해 보이거나 주관적인 판단에 의존해야 합니다. 이전 oracle 분쟁 시스템은 이러한 문제를 해결하기 위해 비효율적이고 확대되는 투표에 의존해 왔습니다. 도전. 그러나 DECO 또는 Town Crier를 사용하면 첫 번째 계층 노드가 올바른 동작을 증명할 수 있습니다. 두 번째 계층 노드에. (두 시스템에 대한 자세한 내용은 섹션 3.6.2를 참조하십시오.) 특히 다음과 같은 경우 두 번째 계층 노드는 첫 번째 계층 노드가 잘못된 보고서 값 ~r을 출력한 것으로 식별합니다. 첫 번째 계층 노드는 DECO 또는 Town Crier를 사용하여 변조 방지 증거를 생성할 수 있습니다. (TLS 지원) 소스에서 ~r을 올바르게 중계하고 있는 두 번째 계층 노드 DON에 의해 권위 있는 것으로 인정되었습니다. 중요한 것은 첫 번째 계층 노드가 이 작업을 수행할 수 있다는 것입니다. 데이터 소스에 직접 액세스해야 하는 2차 계층 노드가 없습니다.17 결과적으로, 원하는 데이터 소스에 대해 Chainlink에서 올바른 판결이 가능합니다. 9.4.4 보험을 잘못 보고함 우리의 staking 메커니즘을 통해 달성된 강력한 뇌물수수 저항은 근본적으로 다음과 같습니다. 경고자에게 수여되는 삭감된 자금에 대해. 금전적 보상이 없으면 경고자는 뇌물을 거부할 직접적인 동기가 없습니다. 그러나 결과적으로 삭감된 자금은 그렇지 않습니다. 잘못된 신고로 인해 피해를 입은 사용자(예: 돈을 잃은 사용자)에게 보상이 가능합니다. 잘못된 가격 데이터가 smart contract에 전달되는 경우. 가정에 따르면 잘못된 보고서는 보고서가 승인된 경우 문제를 일으키지 않습니다. 잠재적인 판결, 즉 두 번째 단계의 조치 후에만 계약을 체결합니다. 설명대로 그러나 가능한 최상의 성능을 달성하기 위해 계약은 대신에 의존할 수 있습니다. 올바른 보고를 시행하는 메커니즘에 대해 낙관적으로 생각합니다. 잠재적인 2차 판결 이전에 보고합니다. 실제로 그러한 낙관적인 행동은 예산이 예산을 초과하지 않는 합리적인 적을 가정하는 우리 모델에서는 안전합니다. staking 메커니즘의 영향. 사용자는 다음과 같은 이유로 메커니즘 오류가 발생할 가능성이 없는 상황을 우려하고 있습니다. 예를 들어, 압도적인 재정 자원을 보유한 적들은 보험을 잘못 보고하는 형태로 추가적인 경제적 보안 계층을 사용하기를 원할 수 있습니다. 우리는 알고있다 이미 이러한 종류의 스마트 계약 기반 정책을 제공하려는 여러 보험사 DAO(예: [7])과 같은 혁신적인 메커니즘을 포함하여 가까운 미래에 Chainlink 보안 프로토콜을 위해. Chainlink에 대한 공연 내역이 존재합니다. 노드 및 지분 금액과 같은 노드에 관한 기타 데이터는 위험에 대한 통계적 평가를 위한 매우 강력한 기반을 제공하여 정책 가격 책정을 가능하게 합니다. 보험 계약자에게는 저렴하면서도 보험사에게는 지속 가능한 방식으로 말입니다. 17Town Crier를 사용하면 1차 노드가 로컬에서 증명을 생성하는 것도 가능합니다. 출력된 보고서의 정확성을 확인하고 이러한 증명을 두 번째 계층 노드에 제공합니다. 필요에 따라.기본적인 형태의 허위신고 보험은 신뢰할 수 있고 smart contracts를 사용하는 효율적인 방식입니다. 간단한 예로 파라메트릭 보험을 들 수 있습니다. 계약 SCins는 인센티브 메커니즘이 다음과 같은 경우 보험 계약자에게 자동으로 보상할 수 있습니다. 두 번째 계층은 첫 번째 계층에서 생성된 보고서의 오류를 식별합니다. 보험 가입을 원하는 사용자 U(예: 대상 생성자) 계약 SC는 분산형 보험사에 보험 금액 요청을 제출할 수 있습니다. 100만 달러 계약. U를 승인하면 보험사는 지속적인(예: 월별) 서비스를 설정할 수 있습니다. SCins의 프리미엄은 $P입니다. U가 보험료를 지불하는 동안 그녀의 보험은 계속 유효합니다. SC에서 보고 실패가 발생하면 결과는 (r1, r2) 쌍의 방출이 됩니다. SC에 대한 충돌 보고서의 경우 r1은 우리 메커니즘의 첫 번째 계층에서 서명되고 해당 수정 보고서인 r2는 두 번째 계층에서 서명됩니다. U가 제공한다면 SCins에 대한 유효한 쌍(r1, r2)인 경우 계약은 자동으로 $M을 지불합니다. 그녀의 보험료 지불은 최신 상태입니다. 9.5 단일 라운드 변형 이전 하위 섹션에 설명된 프로토콜에서는 2단계 위원회가 감시자가 경보를 발령했는지 여부를 확인하기 위해 n 라운드를 기다려야 합니다. 이 요구사항은 낙관적인 경우, 즉 첫 번째 계층이 작동하는 경우에도 유지됩니다. 올바르게. 낙관적으로 보고서를 받아들이고 싶지 않은 사용자의 경우, 즉 잠재적인 판결이 내려지면 해당 접근 방식과 관련된 지연은 실행 불가능할 것입니다. 이러한 이유로 우리는 단 하나의 프로토콜만 필요로 하는 대체 프로토콜도 탐색하고 있습니다. 라운드. 이 접근 방식에서 모든 oracle 노드는 여부를 나타내는 비밀 비트를 제출합니다. 그들은 경고를 보내고 싶어합니다. 그런 다음 두 번째 계층 위원회에서는 이러한 값을 확인합니다. 우선순위. 대략적인 스케치를 제공하기 위해 이러한 계획에는 다음이 포함될 수 있습니다. 단계: 1. Watchdog 비트 제출: 각 노드 Oi는 1비트 Watchdog 값을 비밀 공유합니다. 생성된 모든 보고서에 대해 두 번째 계층의 노드 사이에서 wi ∈{no Alert, Alert}가 발생합니다. 2. 익명 팁: 모든 oracle 노드는 감시 비트가 제출되는 동일한 라운드에서 두 번째 계층 위원회에 익명 팁 α를 제출할 수 있습니다. 이 팁α 현재 보고서에 대해 경고가 발생했음을 나타내는 메시지입니다. 3. 워치독 비트 확인: 2차 위원회에서 oracle 노드의 워치독 공개 비트를 우선순위로 합니다. 노드는 경고하지 않을 때 경고 감시 비트를 보내서는 안 됩니다. 그렇지 않으면 트래픽 분석이 모든 노드의 비트를 드러냅니다. 프로토콜은 경고 없음을 나타냅니다. 우선순위가 가장 높은 경고 워치독보다 우선순위가 높은 노드의 워치독 비트입니다. 밝혀진 내용은 n-라운드 프로토콜의 내용과 동일합니다. 보상은 또한 해당 체계와 동일하게 분배됩니다. 즉, 처음으로 식별된 감시자 잘못된 보고서를 제출한 노드의 예치금을 삭감합니다.익명 제보를 사용하면 경고가 발생하지 않은 경우 2차 위원회가 비대화형 상태를 유지하여 의사소통의 복잡성을 줄일 수 있습니다. 일반적인 경우. 경고를 발생시키는 감시자는 익명 제보를 제출할 경제적 인센티브가 있습니다. 제보가 제출되지 않으면 누구에게도 보상이 지급되지 않습니다. 노드. 익명 제보 α의 보낸 사람 Oi가 식별되지 않도록 하기 위해 네트워크 데이터를 기반으로 적에게 익명 제보를 보낼 수 있습니다. 예를 들어 Tor를 통하거나 보다 실질적으로 클라우드 서비스 제공업체를 통해 프록시되는 채널입니다. 받는 사람 팁이 O에서 시작된 것으로 인증하면 Oi는 링 서명을 사용하여 α에 서명할 수 있습니다[39, 192]. 또는 악의적인 oracle 노드에 의한 2차 위원회에 대한 원인 없는 서비스 거부 공격을 방지하기 위해 α는 다음과 같은 익명 자격 증명이 될 수 있습니다. 취소 가능한 익명성 [73]. 이 프로토콜은 실질적으로 달성 가능하지만 다소 무거운 엔지니어링을 가지고 있습니다. (저희는 이를 줄이는 방법을 모색 중입니다) 예를 들어 첫 번째 계층 노드는 디렉터리 유지 관리가 필요한 두 번째 계층 노드와 직접 통신해야 합니다. 익명 채널 및 링 서명의 필요성이 엔지니어링에 추가됩니다. 계획의 복잡성. 마지막으로, 간략하게 논의된 특별한 신뢰 요구 사항이 있습니다. 아래 메모에. 따라서 우리는 여전히 달성할 수 있는 더 간단한 계획을 모색하고 있습니다. 초선형 staking 영향은 있지만 뇌물 제공자는 점근적으로 최소한 $n log n의 자원을 필요로 하는 2차식보다 덜할 수 있습니다. 아래 계획 중 일부 감시자 역할을 할 노드의 엄격한 하위 집합을 무작위로 선택하는 것을 고려합니다. 이 경우 뇌물 수수 가능성이 특히 강력한 공격이 됩니다. 비고: 이 단일 라운드 staking 메커니즘의 보안에는 접근할 수 없는 기술이 필요합니다. oracle과 2계층 노드 사이의 채널 — 투표[82, 138]와 같은 강제 저항 시스템의 표준 요구 사항이며 실제로는 합리적인 요구 사항입니다. 그러나 추가적으로 뇌물수수자와 협력하려는 노드 Oi는 뇌물 수수자에게 특정 정보를 암호화했음을 보여주는 방식으로 비밀 공유 가치. 예를 들어, Oi가 뇌물 제공자가 어느 노드를 제어하는지 알지 못하는 경우 Oi는 다음을 수행할 수 있습니다. 모든 위원회 구성원에게 가치가 0인 주식을 제출합니다. 그러면 뇌물 제공자는 Oi의 사실을 확인할 수 있습니다. 확률적으로 준수합니다. 단일 라운드 프로토콜에서 이 문제를 피하기 위해 우리는 Oi가 적어도 하나의 정직한 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 생태계에 참여하여 이 백서에서 설명한 다양한 서비스에 대해 네트워크가 지불하는 수수료의 일부를 얻습니다. 분산 ID, 공정한 순서 지정과 같은 고급 서비스에 대한 일반 데이터 피드, 기밀 유지 DeFi. Chainlink 네트워크의 수수료는 서버 운영, 필요한 데이터 라이선스 획득, 유지 관리 등에 대한 노드 운영자의 비용을 지원합니다. 높은 가동 시간을 보장하는 글로벌 직원. FFO는 서비스 수수료, 순 비용을 나타냅니다. 노드가 미래에 이익을 얻거나 잘못된 동작을 보여주면 잃을 것입니다. FFO는 네트워크 보안에 도움이 되는 지분 형태입니다. FFO의 유용한 기능은 온체인 데이터(오프체인으로 보완됨)입니다. 데이터) 노드 이력에 대한 높은 신뢰 기록을 수립하여 FFO 계산을 가능하게 합니다. 투명하고 경험적으로 주도되는 방식으로. FFO에 대한 간단한 1차 측정은 특정 기업의 평균 순수익에서 파생될 수 있습니다. 일정 기간 동안의 노드(예: 총 수익에서 운영 비용을 뺀 값) FFO는 다음을 수행할 수 있습니다. 예를 들어 누적 미래 순수익의 순 현재 가치 [114]로 계산됩니다. 즉, 미래의 모든 수입을 시간으로 할인한 가치입니다. 그러나 노드 수익은 그림 17에서 볼 수 있듯이 변동이 심할 수 있습니다. 더 중요한 것은 노드 수익이 고정된 분포를 따르지 않을 수 있다는 것입니다. 시간이 지남에 따라. 결과적으로 FFO 추정 시 탐구할 다른 요소는 다음과 같습니다. • 성과 내역: 보고서의 정확성과 적시성, 가동 시간을 포함한 운영자의 성과 내역은 목표를 제공합니다. 사용자가 신뢰성을 평가할 수 있는 시금석입니다. 실적 내역은 다음과 같습니다. 사용자가 oracle 노드를 선택하는 데 중요한 요소를 제공합니다(또는 출현과 함께). DON 중, DON 중 선택). 강력한 실적 이력이 있을 가능성이 높습니다. 지속적인 높은 수익과 상관관계가 있습니다.18 18우리가 다루고자 하는 중요한 연구 문제는 위조된 서비스 양을 탐지하는 것입니다.그림 17: 단일 데이터 피드(ETH-USD)에서 Chainlink 노드가 얻은 수익 2021년 3월의 대표적인 주간. • 데이터 액세스: oracles는 개방형 API에서 다양한 형태의 데이터를 얻을 수 있지만 특정 형태의 데이터나 특정 고품질 소스는 구독 기반 또는 계약 계약을 통해. 특정에 대한 특권적 접근 데이터 소스는 안정적인 수익원을 창출하는 역할을 할 수 있습니다. • DON 참여: DONs의 출현으로 노드 커뮤니티가 등장할 것입니다. 특별한 서비스를 제공하기 위해 함께 모입니다. 많은 DON에 포함될 것으로 예상됩니다. 선택적으로 운영자를 통해 평판이 좋은 DON에 참여하도록 설정합니다. 일관된 수익원을 보장하는 데 도움이 되는 특권적인 시장 지위. • 크로스 플랫폼 활동: 일부 노드 운영자는 PoS validators 또는 blockchain 이외의 컨텍스트의 데이터 공급자. 이러한 다른 시스템에서의 성과(데이터가 신뢰할 수 있는 형식으로 제공되는 경우)는 평가에 정보를 제공할 수 있습니다. 그들의 공연 기록. 마찬가지로 Chainlink 네트워크의 잘못된 동작 사용자를 몰아냄으로써 다른 시스템의 수익을 위태롭게 할 수 있습니다(예: FFO). 여러 플랫폼으로 확장할 수 있습니다. 9.6.2 투기적 FFO 노드 운영자는 단지 수익을 창출하기 위해 Chainlink 네트워크에 참여하지 않습니다. 그러나 작업을 실행하기 위한 새로운 기회를 활용하기 위해 스스로를 만들고 위치를 정하는 것입니다. 즉, 네트워크 내 oracle 노드의 지출도 DeFi 및 기타 스마트 계약 애플리케이션의 미래에 대한 긍정적인 진술 도메인뿐만 아니라 oracle 네트워크의 새로운 비 blockchain 애플리케이션도 포함됩니다. 오늘날 노드 운영자는 기존 Chainlink 네트워크에서 사용 가능한 수수료를 얻는 동시에 동시에 이는 문제가 인터넷 사이트에서 더 쉽다는 점을 제외하면 인터넷 사이트의 가짜 리뷰와 어느 정도 유사합니다. oracle 상품이 주문되었는지, 즉 보고서가 주문되었는지에 대한 확실한 기록이 있기 때문에 설정됩니다. 예를 들어 온라인 상점에서 주문한 실제 상품과 반대되는 배송입니다. 다른 말로 하면 oracle에서 고객의 진실성은 검증할 수 없더라도 설정을 통해 성능을 검증할 수 있습니다.평판, 실적 이력, 운영 전문성을 구축하여 입지를 다질 것입니다. 미래 네트워크에서 사용할 수 있는 수수료를 얻는 데 유리합니다(물론 조건에 따라). 정직한 행동에 대해). 현재 Chainlink 생태계에서 운영되는 노드는 다음과 같습니다. Chainlink 추가 수수료를 받는 데 신규 이민자보다 유리하다는 의미입니다. 서비스가 가능해집니다. 이러한 이점은 새로운 운영업체는 물론 평판이 좋은 기술 회사에도 적용됩니다. 예를 들어 T-Systems는 전통적인 기술 제공업체(Deutsche Telekom의 자회사)와 대규모 중앙 집중식 회사인 Kraken Exchange는 Chainlink 생태계 [28, 143]에서 초기 입지를 구축했습니다. 향후 기회에 oracle 노드가 참여하는 것은 그 자체로 간주될 수 있습니다. 일종의 투기적 FFO로서 Chainlink의 지분 형태를 구성합니다. 네트워크. 9.6.3 외부 평판 우리가 설명한 대로 IIF는 엄격한 가명으로 네트워크에서 작동할 수 있습니다. 즉, 관련된 사람이나 실제 실체를 공개하지 않습니다. 그러나 사용자가 공급자를 선택할 때 잠재적으로 중요한 요소 중 하나는 외부입니다. 평판. 외부 평판이란 가명이 아닌 실제 신원에 부여된 신뢰성에 대한 인식을 의미합니다. 평판 위험 실제 정체성은 암묵적인 인센티브의 한 형태로 볼 수 있습니다. 평판을 본다 즉, 암호경제학적 의미에서 IIF의 렌즈를 통해 FFO 추정치에 통합될 수 있는 크로스 플랫폼 활동. FFO 추정의 요인으로 외부 평판을 사용하는 이점은 이와 반대로 가명 연결은 외부 평판이 성과를 단순히 연결하는 것이 아니라 운영자의 기존 활동뿐만 아니라 향후 활동에도 적용됩니다. 예를 들어 평판이 좋지 않은 경우 개인에게 부착되면 그 사람의 미래 사업을 오염시킬 수 있습니다. 다르게 말하면, 외부 평판은 가명보다 더 넓은 범위의 FFO를 포착할 수 있습니다. 개인 또는 확립된 불법 행위의 영향으로서의 성과 기록 회사는 가명 운영과 관련된 것보다 탈출하기가 더 어렵습니다. Chainlink은(는) 분산형 ID 기술(섹션 4.3)과 호환됩니다. IIF에서 외부 평판 사용에 대한 지원을 제공할 수 있습니다. 이러한 기술 운영자가 주장하는 실제 세계의 진실성을 검증하고 보장하는 데 도움이 될 수 있습니다. 신원.19 9.6.4 IIF 분석 열기 앞서 언급했듯이 IIF는 신뢰할 수 있는 오픈 소스 데이터와 도구를 제공하는 것을 목표로 합니다. 암시적 인센티브 분석. 목표는 지역사회 내에서 서비스 제공자를 활성화하는 것입니다. 다양한 부분의 위험 평가 요구에 맞는 분석을 개발합니다. Chainlink 사용자 기반. 19분산형 신원 증명은 원하는 경우 검증된 인증을 통해 가명을 장식할 수도 있습니다. 보충 정보. 예를 들어, 노드 운영자는 원칙적으로 그러한 자격 증명을 사용하여 다음을 수행할 수 있습니다. 어떤 회사인지 밝히지 않고 Fortune 500대 기업임을 입증합니다.노드의 수익 및 성능에 관한 상당한 양의 과거 데이터 신뢰도가 높고 변경 불가능한 형태로 체인에 상주합니다. 그러나 우리의 목표는 오직 눈에만 보이는 행동에 대한 데이터를 포함한 가장 포괄적인 데이터 오프체인 보고(OCR) 또는 DON 활동과 같은 체인. 이러한 데이터는 잠재적으로 방대하다. 데이터를 저장하고 무결성을 보장하는 가장 좋은 방법입니다. 변조는 논의된 기술을 사용하여 DONs의 도움을 받을 것이라고 믿습니다. 섹션 3.3에서. 일부 인센티브는 staking와 같은 직접적인 측정 형태에 적합합니다. 예금 및 기본 FFO. 투기적 FFO 및 평판과 같은 다른 것들은 파악하기가 더 어렵습니다. 객관적인 방식으로 측정하지만, 다음을 포함한 뒷받침하는 데이터 형태가 있다고 믿습니다. Chainlink 생태계의 역사적 성장, 평판에 대한 소셜 미디어 지표 등 정량화하기 어려운 요소에 대해서도 IIF 분석 모델을 지원할 수 있습니다. 우리는 특별히 모니터링, 검증 및 확인을 위해 전용 DON이 발생한다고 상상할 수 있습니다. 노드의 오프체인 성능 기록과 관련된 데이터 및 기타 데이터를 기록합니다. 검증된 신원 정보와 같이 IIF에서 사용됩니다. 이러한 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이 증가합니다. 덕분에 인센티브 시스템 설계의 초선형 staking 영향, 경제적 안정 시스템은 n보다 빠르게 상승할 것입니다. 예를 들어 섹션 9.4에서 설명한 메커니즘의 n2와 같습니다. 결과적으로 경제적 안정을 위한 평균 비용, 즉 기여하는 지분의 양은 1달러의 경제적 안정이 떨어질 것입니다. 따라서 네트워크는 사용자에게 요금을 청구할 수 있습니다. 더 낮은 수수료. oracle 서비스에 대한 수요가 탄력적이라고 가정합니다(예: 간략한 내용은 [31] 참조). 설명) 수요가 증가하여 추가 수수료와 FFO가 발생합니다. 다음 예를 통해 이 점을 설명합니다. 예시 5. 인센티브를 통해 oracle 네트워크의 경제적 보안이 강화된 이후 계획은 \(dn2 for stake \)dn이며, 1달러 지분으로 인한 경제적 안정입니다. n은 경제적 안정의 달러당 평균 비용, 즉 지분의 양입니다. 1달러의 경제적 안정에 기여하는 금액은 1/n입니다. 경제적 인센티브가 전적으로 FFO로 구성된 네트워크를 생각해 보세요. 노드당 \(d ≤\)10K입니다. 네트워크에 n = 3개의 노드가 있다고 가정합니다. 그러면 평균비용 경제적 안정의 1달러당 약 0.33달러입니다. 네트워크의 총 FFO가 \(30K (e.g., to \)31K 이상으로 증가한다고 가정합니다. 주어진 노드당 FFO의 한도를 늘리면 네트워크는 (적어도) n = 4로 성장합니다. 이제 평균 비용은 경제적 안정의 1달러당 약 0.25달러로 떨어집니다. 우리는 그림 18에서 oracle 네트워크의 경제적 안정의 전체 선순환을 개략적으로 설명합니다. 경제 안보의 선순환은 다음과 같은 효과에서 비롯된다는 점을 강조합니다. 사용자가 수수료를 합산합니다. 더 큰 이익을 위해 일하는 것은 그들의 집단 FFO입니다. 네트워크 규모가 커지고 집단 보안이 강화됩니다. 우리는 또한 선순환이 경제적 안정은 DON의 재정적 지속 가능성 달성에 유리합니다. 한 번 사용자 요구 사항을 해결하는 DON이 생성된 지점 이상으로 성장해야 합니다. 수수료 수익이 oracle 노드의 운영 비용을 초과합니다.
그림 18: Chainlink staking의 선순환 도식. 사용자 수수료 인상 oracle 네트워크 1⃝에 지불하면 네트워크가 성장하고 경제적 성장으로 이어집니다. 보안 2⃝. 이러한 초선형 성장은 Chainlink 네트워크에서 규모의 경제를 실현합니다. 3⃝. 구체적으로 이는 경제적 안정을 위한 평균 비용의 감소를 의미합니다. 수수료 지불 또는 기타 지분 소스에서 발생하는 달러당 경제적 안정 증가합니다. 비용 절감이 사용자에게 전달되어 oracle에 대한 수요 증가를 촉진합니다. 서비스 4⃝. 9.9 네트워크 성장을 이끄는 추가 요인 Chainlink 생태계가 계속 확장됨에 따라 우리는 그 매력을 믿습니다. blockchain 경제를 위한 인프라로서의 중요성이 가속화될 것입니다. oracle 네트워크가 제공하는 가치는 초선형적이므로 더 빠르게 성장합니다.네트워크 자체의 크기보다 이러한 가치 성장은 두 가지 모두에서 비롯됩니다. 규모의 경제 - 서비스 양이 증가함에 따라 사용자당 비용 효율성이 향상됩니다. 네트워크 효과 - 사용자가 DON을 더 광범위하게 채택함에 따라 네트워크 유틸리티가 증가합니다. 기존 smart contract은 계속해서 더 많은 가치를 확보하고 완전히 새로운 것을 보여줍니다. smart contract 애플리케이션은 보다 분산화된 서비스를 통해 가능해지며, 총 DONs의 사용 및 총 수수료가 증가해야 합니다. 수수료 풀 증가 더욱 분산화된 서비스를 창출하기 위한 수단과 인센티브로 전환됩니다. 결과적으로 선순환이 됩니다. 이 선순환은 닭고기와 달걀의 중요한 문제를 해결합니다. 하이브리드 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의 진화에 대한 비전을 제시했습니다. 주요 테마 이 비전에는 훨씬 더 광범위한 서비스를 제공할 수 있는 네트워크의 능력이 있습니다. 단순한 데이터 전달보다 smart contracts. DON을 미래의 분산형 서비스의 기반으로 사용하여 Chainlink은 성능과 기밀성이 강화된 oracle 기능을 제공하는 것을 목표로 합니다. oracle 네트워크는 강력한 신뢰 최소화를 제공합니다. staking과 같은 원칙적인 암호 경제 메커니즘의 조합을 통해 메인 체인에 의존하여 신중하게 고안된 가드레일과 서비스 수준 시행. DONs는 또한 레이어 2 시스템이 트랜잭션에 대해 유연하고 공정한 주문 정책을 시행하고 멤풀 라우팅 트랜잭션에 대한 가스 비용을 줄이는 데 도움이 됩니다. 함께 찍은, 이러한 기능은 모두 안전하고 풍부한 기능을 갖춘 하이브리드 스마트의 방향으로 나아가고 있습니다. 계약. DONs의 유연성은 기존 Chainlink 서비스를 향상시키고 많은 추가 smart contract 기능 및 응용 프로그램. 그 중에는 원활한 다양한 오프체인 시스템과의 연결, 분산형 ID 생성 기존 데이터, 인프라에 중요한 정보를 적시에 제공하는 데 도움이 되는 우선순위 채널 거래 및 기밀 유지 DeFi 도구. 우리가 여기서 제시한 비전은 야심적입니다. 단기적으로는 역량 강화를 추구합니다. 현재 smart contracts의 도달 범위를 넘어서는 목표를 달성하기 위한 하이브리드 계약을 체결하는 동시에 장기적으로 우리는 분산형 금속층을 구현하는 것을 목표로 하고 있습니다. 행복하게 그릴 수 있어요 합의 알고리즘부터 영지식 증명까지 다양한 새로운 도구와 아이디어 빠르게 발전하는 연구의 결과로 커뮤니티가 발전하고 있는 시스템입니다.
마찬가지로, 우리는 이에 대한 대응으로 이 백서의 아이디어 구현을 우선시할 것으로 기대합니다. Chainlink 사용자 커뮤니티의 요구에 부응합니다. 우리는 다음 단계를 기대합니다 보편적인 연결을 통해 smart contracts에게 권한을 부여하고 세계 차세대 금융의 중추로서의 분산형 기술 그리고 법률 시스템. 감사의 말 이 문서에 그림을 제공한 Julian Alterini와 Shawn Lee에게 감사드립니다.