Chainlink: شبكة أوراكل اللامركزية

Özet

Bu teknik incelemede, Chainlink'nin orijinal Chainlink teknik incelemesindeki ilk konseptinin ötesindeki evrimine ilişkin bir vizyon ortaya koyuyoruz. öngörüyoruz oracle ağları için, mevcut ve yeni blockchain'leri hızlı, güvenilir ve gizliliği koruyan evrensel bağlantı ve zincir dışı hesaplama smart contracts. Planımızın temeli Merkezi Olmayan Oracle Ağları dediğimiz şeydir veya Kısaca DONs. DON, Chainlink komitesi tarafından bakımı yapılan bir ağdır düğümler. Seçilen oracle fonksiyonlarının sınırsız aralığından herhangi birini destekler. Komite tarafından dağıtılır. Bir DON bu nedenle güçlü bir soyutlama katmanı görevi görür, smart contracts için kapsamlı zincir dışı kaynaklara ve son derece yüksek düzeyde arayüzler sunan DON içinde verimli ancak merkezi olmayan zincir dışı bilgi işlem kaynakları. DONs sıçrama tahtası olarak kullanıldığında, Chainlink yedi alandaki ilerlemelere odaklanmayı planlıyor kilit alanlar: • Hibrit smart contracts: Zincir üzerinde güvenli bir şekilde oluşturarak mevcut smart contract yeteneklerini artırmak için güçlü, genel bir çerçeve sunar ve zincir dışı bilgi işlem kaynaklarını hibrit smart contracts dediğimiz şeye aktarıyoruz. • Karmaşıklığı ortadan kaldırmak: Geliştiricilere ve kullanıcılara basit çözümler sunmak işlevsellik, karmaşık temel bilgilere aşina olma ihtiyacını ortadan kaldırır protokoller ve sistem sınırları. • Ölçeklendirme: oracle hizmetlerinin gecikmelere ve aktarım hızlarına ulaşmasını sağlamak yüksek performanslı merkezi olmayan sistemler tarafından talep edilmektedir. • Gizlilik: blockchains'yi birleştiren yeni nesil sistemlerin etkinleştirilmesi hassas kişiler için güçlü yeni gizlilik korumalarıyla doğuştan gelen şeffaflık veri. • İşlemler için sipariş adaleti: İşlem sıralamasını çeşitli yollarla destekleme Son kullanıcılar için adil olan ve önden çalıştırma ve diğer saldırıları önleyen botlar ve sömürücü madenciler. • Güvenin en aza indirilmesi: Son derece güvenilir bir destek katmanı oluşturmak smart contracts ve diğer oracle bağımlı sistemler, merkezi olmayan yönetim, yüksek güvenlikli blockchains'ye güçlü sabitleme, kriptografik teknikler ve kriptoekonomik garantiler. • Teşvik tabanlı (kriptoekonomik) güvenlik: DONs'deki düğümlerin, iyi kaynaklara sahip rakipler karşısında bile güvenilir ve doğru davranmak için güçlü ekonomik teşviklere sahip olmasını sağlayan mekanizmaların titizlikle tasarlanması ve sağlam bir şekilde dağıtılması. Chainlink topluluğunun ön ve devam eden yeniliklerini sunuyoruz Bu alanların her birinde genişlemenin ve giderek artan Chainlink ağı için planlanan güçlü özellikler.

giriiş

Blockchain oracle'ler günümüzde genellikle tek bir amacı olan merkezi olmayan hizmetler olarak görülüyor: zincir dışı kaynaklardan verileri blockchains'ye iletmek için. Kısa bir adım olsa da Verilerin iletilmesinden, üzerinde işlem yapılmasına, saklanmasına veya çift yönlü olarak iletilmesine kadar. Bu gözlem, oracles'nin işlevselliğine ilişkin çok daha geniş bir kavramı doğrulamaktadır. O da öyle smart contracts'nin artan hizmet gereksinimlerini karşılıyor ve giderek daha çok yönlü hale geliyor oracle ağlarına dayanan teknolojiler. Kısacası, bir oracle şunu yapabilir ve gerektirecektir: Zincir içi ve zincir dışı sistemler arasında genel amaçlı, çift yönlü, bilgi işlem özellikli bir arayüz olmalıdır. Oracles'ın blockchain ekosistemindeki rolü geliştirmektir smart contracts'nin performansını, işlevselliğini ve birlikte çalışabilirliğini Çok sayıda sektöre yeni güven modelleri ve şeffaflık getiriyoruz. Bu dönüşüm, hibrit smart contract'lerin kullanımının genişletilmesiyle gerçekleşecek. blockchains'nin zincir dışı sistemlerin benzersiz yeteneklerine sahip özel özellikleri oracle ağları oluşturur ve böylece zincir üstü sistemlerden çok daha fazla erişim ve güce ulaşır izolasyonda. Bu teknik incelemede, Chainlink 2.0 olarak adlandırdığımız, orijinal Chainlink teknik inceleme [98]'deki ilk konseptinin ötesinde Chainlink evrimi olarak adlandırdığımız şeye yönelik bir vizyon ifade ediyoruz. oracle ağları için giderek daha geniş bir rol öngörüyoruz; hibrit için hızlı, güvenilir ve gizliliği koruyan evrensel bağlantı ve bilgi işlem sağlayarak mevcut ve yeni blockchain'leri tamamlar ve geliştirirler smart contracts. oracle ağlarının yardımcı hizmetlere dönüşeceğine bile inanıyoruz yüksek bütünlüklü blockchain dereceli verileri blockchain ötesindeki sistemlere aktarmak için ekosistem. Bugün, çeşitli varlıklar kümesi tarafından yönetilen Chainlink düğümleri, oracle ağlarında bir araya gelerek rapor olarak bilinen şekilde smart contracts'ye veri aktarıyor. Böyle görüntüleyebiliriz oracle klasik fikir birliğine benzer bir komite olarak düğümler blockchain [72], ancak bağımsız işlevsellik sağlamak yerine mevcut blockchain'leri destekleme hedefiyle. Doğrulanabilir rastgele işlevler (VRF) ve Zincir Dışı Raporlama ile (OCR), Chainlink halihazırda smart contracts'nin ihtiyaç duyduğu hesaplama kaynaklarını sağlamaya yönelik genel amaçlı bir çerçeveye ve altyapıya doğru evriliyor. gelişmiş işlevsellik. Chainlink 2.0 planımızın temeli Merkezi Olmayan Oracle adını verdiğimiz şeydir Ağlar veya kısaca DONs. “oracle ağ” terimini kullanıma sunduğumuzdan beri orijinal Chainlink teknik inceleme [98], oracles her zamankinden daha zengin işlevsellik geliştirdi ve uygulama genişliği. Bu yazıda, terimin yeni bir tanımını sunuyoruz. Chainlink ekosistemine yönelik gelecek vizyonumuza. Bu görünümde, DON bir ağdır Chainlink düğümden oluşan bir komite tarafından sürdürülür. Bir fikir birliği protokolüne dayanan bu tarafından dağıtım için seçilen sınırsız aralıktaki oracle işlevlerinden herhangi birini destekler komite. Dolayısıyla bir DON, arayüzler sağlayan bir blockchain soyutlama katmanı görevi görür hem smart contracts hem de diğer sistemler için zincir dışı kaynaklara. Ayrıca sağlar Yüksek verimli ancak merkezi olmayan zincir dışı bilgi işlem kaynaklarına erişim. Genel olarak, a DON ana zincirdeki işlemleri destekler. Amacı güvenli ve esnek bir hizmet sunmaktır.Zincir içi ve zincir dışı hesaplamayı birleştiren ble hibrit smart contracts dış kaynaklara bağlantı. DONs'deki komitelerin kullanımında bile Chainlink'nin kendisinin olduğunu vurguluyoruz doğası gereği izinsiz kalır. DON'ler izinsiz bir uygulamanın temeli olarak hareket eder özel oracle ağlarını uygulamak için düğümlerin bir araya gelebileceği çerçeve izinli veya izinsiz olabilen düğümlerin dahil edilmesi için kendi rejimleri. DONs temel alınarak, Chainlink 2.0'da yedi alandaki ilerlemelere odaklanmayı planlıyoruz temel alanlar: hibrit smart contracts, karmaşıklığın ortadan kaldırılması, ölçeklendirme, gizlilik, işlemlerde adil düzen, güven minimizasyonu ve teşvik temelli (kriptoekonomik) güvenlik. Bu makalenin girişinde Merkezi Olmayanlara genel bir bakış sunuyoruz Bölüm 1.1'de Oracle Networks ve ardından Bölüm 1.2'de yedi temel yenilik alanımız. Bu makalenin geri kalanının organizasyonunu Bölüm 1.3'te açıklıyoruz. 1.1 Merkezi Olmayan Oracle Ağları Merkezi Olmayan Oracle Ağları, yetenekleri geliştirmek ve genişletmek için tasarlanmıştır smart contracts hedefindeki blockchain veya ana zincirdeki işlevler aracılığıyla yerel olarak mevcut değildir. Bunu, içinde bulunan üç temel kaynağı sağlayarak yaparlar. bilgi işlem sistemleri: ağ oluşturma, depolama ve hesaplama. Bir DON şunu sunmayı amaçlamaktadır: Bu kaynaklar güçlü gizlilik, bütünlük ve kullanılabilirlik özelliklerine1 sahiptir. aynı zamanda sorumluluk. DON'ler, belirli bir görevi yerine getirmek için işbirliği yapan oracle düğümlerinden oluşan komiteler tarafından oluşturulur. kalıcı hizmetler sağlamak için bir işte çalışmayı veya uzun süreli bir ilişki kurmayı seçmeyi seçin müşterilere. DON'ler blockchain-agnostik bir şekilde tasarlanmıştır. olarak hizmet edeceklerine söz veriyorlar uygulama geliştiricilerinin zincir dışı destek oluşturması için güçlü ve esnek bir araç desteklenen herhangi bir ana zincirdeki smart contract'leri. İki tür işlevsellik, bir DON'nin yeteneklerini gerçekleştirir: yürütülebilir dosyalar ve adaptörler. Yürütülebilir dosyalar, DON üzerinde sürekli ve merkezi olmayan bir şekilde çalışan programlardır. Ana zincir varlıklarını doğrudan saklamasalar da, yüksek performans ve gizli işlemleri gerçekleştirme yeteneği gibi önemli avantajlara sahiptirler. hesaplama. Yürütülebilir dosyalar DON üzerinde bağımsız olarak çalışır ve deterministik performans sergiler operasyonlar. DON öğesini harici kaynaklara bağlayan bağdaştırıcılarla birlikte çalışırlar ve yürütülebilir dosyalar tarafından çağrılabilir. DONs için öngördüğümüz adaptörler, Chainlink'deki harici bağdaştırıcıların bugün genelleştirilmesi. Mevcut adaptörler genellikle yalnızca veri kaynaklarından veri alır; bağdaştırıcılar çift yönlü olarak çalışabilir; içinde DONs, ayrıca şu amaçlara ulaşmak için DON düğümlerinin ortak hesaplamasından da yararlanabilirler gizliliği koruyan tüketim için raporların şifrelenmesi gibi ek özellikler yürütülebilir bir dosya. DON'nin temel işleyişine ilişkin bir fikir vermek için Şekil 1, kavramsal olarak bir DON'nin nasıl çalıştığını göstermektedir. DON, raporları blockchain adresine göndermek ve böylece geleneksel, mevcut oracle işlevselliğini elde etmek için kullanılabilir. DONs, bunun ötesinde pek çok ek özellik sağlayabilir 1Bilgi güvenliğinin “CIA üçlüsü” [123, s. 26, §2.3.5].Chainlink adlı kişinin mevcut ağları. Örneğin, Şekil 1'in genel yapısı içinde, yürütülebilir dosya, getirilen varlık fiyatı verilerini DON'ye kaydedebilir ve bu verileri kullanarak örneğin raporları için takip eden bir ortalama hesaplayın. Şekil 1: Merkezi Olmayan Oracle Ağının temel oracle işlevselliğini, yani zincir dışı verileri bir sözleşmeye aktarmayı nasıl gerçekleştirebileceğini örnek olarak gösteren kavramsal şekil. bir yürütülebilir dosya, üzerinde hesapladığı zincir dışı verileri almak ve çıktı göndermek için bağdaştırıcılar kullanır başka bir adaptör üzerinden blockchain hedefine. (Bağdaştırıcılar aşağıdaki kodla başlatılır: DON, küçük mavi kutularla temsil edilir; oklar bunun için veri akışının yönünü gösterir özel bir örnek.) Yürütülebilir dosya ayrıca yerel DON dosyasını okuyabilir ve yazabilir. durumu korumak ve/veya diğer yürütülebilir dosyalar ile iletişim kurmak için depolama. Tamamı burada temsil edilen DONs'deki esnek ağ oluşturma, hesaplama ve depolama, bir dizi yeniliğe olanak sağlar uygulamalar. DONs'nin en büyük avantajı, yeni blockchain hizmetlerini ön yükleme yeteneğidir. DONs mevcut oracle ağlarının servis uygulamalarını hızla destekleyebileceği bir araçtır bugün bu, amaca yönelik ağların oluşturulmasını gerektirecektir. bir sayı veriyoruz Bu tür uygulamaların örnekleri Bölüm 4'te verilmiştir. Bölüm 3'te, DONs hakkında daha fazla ayrıntı sunarak yeteneklerini açıklıyoruz: geliştiricilere ve kullanıcılara sundukları arayüzün şartları. 1.2 Yedi Temel Tasarım Hedefi Burada, yukarıda sıralanan yedi temel odağı kısaca gözden geçireceğiz. Chainlink, yani:Hibrit smart contracts: Chainlink vizyonumuzun merkezinde güvenli bir şekilde smart contracts'de zincir içi ve zincir dışı bileşenleri birleştiriyor. Sözleşmelere atıfta bulunuyoruz bu fikri hibrit smart contracts veya hibrit sözleşmeler olarak hayata geçirmek.2 Blockchain'ler merkezi olmayan hizmette iki kritik rol oynamaya devam edecek ekosistemler: Her ikisi de kripto para sahipliğinin temsil edildiği yerdir ve merkezi olmayan hizmetler için sağlam dayanaklar. Bu nedenle akıllı sözleşmelerin zincir üzerinde temsil edilmesi veya yürütülmesi gerekir, ancak zincir üzerindeki yetenekleri ciddi şekilde sınırlıdır. tamamen Zincir üstü sözleşme kodu yavaş, pahalı ve dar görüşlü olduğundan gerçek dünyadan yararlanamıyor gizli hesaplamanın çeşitli biçimleri, (sözde)rastgelelik güvenliğinin oluşturulması da dahil olmak üzere, zincirde doğası gereği elde edilmesi mümkün olmayan çeşitli veriler ve çeşitli işlevler madenciye / validator manipülasyona vs. karşı. smart contracts'nin tam potansiyelini gerçekleştirmesi bu nedenle smart contracts'ye ihtiyaç duyar iki parçadan oluşacaktır: zincir üstü parça (bunu genellikle SC olarak gösteririz) ve DON üzerinde çalışan bir yürütülebilir dosya olan zincir dışı bir parça (bunu genellikle şu şekilde belirtiriz: yönetici). Amaç, zincir üstü işlevselliğin güvenli bir bileşimini elde etmektir. DONs'in sağlamayı amaçladığı zincir dışı hizmetlerin çokluğu. İki parça birlikte Hibrit bir sözleşme oluşturun. Bu fikri kavramsal olarak Şekil 2'de sunuyoruz. Zaten bugün, Veri beslemeleri ve VRF'ler gibi Chainlink hizmetler3, başka türlü elde edilemeyecek olanak sağlıyor Daha genel bir çerçeveye doğru ilk adımlar olarak, DeFi'dan adil şekilde oluşturulmuş NFT'lara ve merkezi olmayan sigortaya kadar uzanan smart contract uygulamaları. Chainlink hizmetleri olarak Bu teknik incelemedeki vizyonumuza göre genişletin ve daha performanslı bir şekilde büyüyün smart contract sistemlerinin gücü tüm blockchain'lerde olacak. Bu teknik incelemedeki diğer altı temel odak noktamız, hizmette hareket etmek olarak görülebilir hibrit sözleşmelerden ilki, kapsayıcı olanı. Bu odaklar görünür öğelerin kaldırılmasını içerir Hibrit sözleşmelerden kaynaklanan karmaşıklık, ek zincir dışı hizmetler yaratılması her zamankinden daha yetenekli hibrit sözleşmelerin oluşturulması ve güvenin en aza indirilmesi durumunda hibrit sözleşmelerle elde edilen güvenlik özelliklerinin desteklenmesi. Fikri bırakıyoruz Makalenin çoğunda örtülü olarak hibrit sözleşmeler yer alıyor, ancak bunların herhangi bir kombinasyonu DON ile MAINCHAIN mantığı hibrit bir sözleşme olarak görülebilir. Karmaşıklığı soyutlamak: DON'ler merkezi olmayan uygulamalardan yararlanmak üzere tasarlanmıştır Genellikle karmaşık makineleri soyutlayarak geliştiriciler ve kullanıcılar için kolay sistemler DONs'nin güçlü ve esnek hizmet yelpazesinin arkasında. Mevcut Chainlink hizmetleri zaten bu özellik var. Örneğin, bugün Chainlink'deki veri akışları, geliştiricilerin, OCR'nin bir grup arasında fikir birliği raporlamasını zorunlu kıldığı araçlar gibi, protokol düzeyindeki ayrıntılarla ilgilenmelerini gerektirmeyen zincir içi arayüzler sunmaktadır. 2Zincir üstü/zincir dışı sözleşme bileşimi fikri daha önce çeşitli kısıtlı formlar, örneğin katman-2 sistemleri, TEE tabanlı blockchains [80] vb. Amacımız desteklemek ve genelleştirmektir Bu yaklaşımlar ve bunların zincir dışı veri erişimini ve diğer anahtarları kapsayabilmesini sağlar oracle hizmetler. 3Chainlink hizmetler, aşağıdakiler aracılığıyla sunulan çeşitli merkezi olmayan hizmetlerden ve işlevlerden oluşur: ağ. Çeşitli oracle ağlardan oluşan çok sayıda düğüm operatörü tarafından sunulurlar ekosistem genelinde.Şekil 2: Zincir içi/zincir dışı sözleşme kompozisyonunu gösteren kavramsal şekil. bir hibrit smart contract 3⃝iki tamamlayıcı bileşenden oluşur: zincir üstü bir bileşen blockchain üzerinde yerleşik SC 1⃝ bileşeni ve zincir dışı bileşen yöneticisi 2⃝ DON üzerinde yürütülür. DON aynı zamanda iki bileşen arasında bir köprü görevi de görür Hibrit sözleşmeyi web hizmetleri gibi zincir dışı kaynaklara bağlamak ve diğer blockchains, merkezi olmayan depolama vb. merkezi olmayan düğüm kümesi. DONs, kapsamı genişletme anlamında bir adım daha ileri gidiyor Chainlink'un geliştiricilere bir soyutlama katmanı sunabileceği hizmet yelpazesi üst düzey hizmetler için geliştirilmiş arayüzler. Bölüm 4'te bu yaklaşımı vurgulayan çeşitli uygulama örnekleri sunuyoruz. Örneğin işletmelerin DONs'yi bir tür güvenli ara katman yazılımı olarak kullanmasını öngörüyoruz. eski sistemlerini blockchains'ye bağlayın. (Bkz. Bölüm 4.2.) DONs'nin bu kullanımı, genel blockchain dinamiklerinin (ücretler, yeniden düzenlemeler vb.) karmaşıklığını ortadan kaldırır. Aynı zamanda belirli blockchain'lerin özelliklerini soyutlayarak işletmelerin mevcut sistemlerini sürekli genişleyen bir blockchain sistemleri dizisine bağlamalarına olanak tanır. bu sistemlerde veya daha genel olarak merkezi olmayan sistemlerin geliştirilmesinde uzmanlaşmış uzmanlığa ihtiyaç duyulmaktadır. Sonuçta hedefimiz Chainlink ile elde edilen soyutlama derecesini artırmaktır. Merkezi olmayan bir meta katman olarak adlandırdığımız şeyi uygulama noktasına kadar. Böyle bir katman tüm geliştirici sınıfları için zincir içi/zincir dışı ayrımını ortadan kaldıracaktır ve DApp kullanıcıları, merkezi olmayan hizmetlerin sorunsuz bir şekilde oluşturulmasına ve kullanılmasına olanak tanır.Geliştirme sürecini basitleştirmek için geliştiriciler meta katmandaki DApp işlevselliğini birleşik bir makine modelinde sanal bir uygulama olarak belirleyebilir. Yapabilirlerdi daha sonra DApp'i otomatik olarak başlatmak için merkezi olmayan bir meta katman derleyicisi kullanın. blockchains, DONs ve DONs'yi kapsayan bir dizi birlikte çalışan merkezi olmayan işlevsellik dış hizmetler. (Bu harici hizmetlerden biri, meta katmanı eski kurumsal sistemleri içeren uygulamalar için yararlı kılan bir kurumsal sistem olabilir.) derleme, modern derleyicilerin ve yazılım geliştirme kitlerinin (SDK'ler) işleyişine benzer. heterojen donanımın tam potansiyelini kullanma konusunda genel programcıları desteklemek genel amaçlı bir CPU ve GPU'lar gibi özel donanımlardan oluşan mimariler, makine öğrenimi hızlandırıcıları veya güvenilir yerleşim bölgeleri. Şekil 3 bu fikri kavramsal düzeyde sunmaktadır. Hibrit smart contract'ler bu vizyona ve meta sözleşmeler dediğimiz kavrama giden yolda ilk adımdır. Meta sözleşmeler merkezi olmayan bir platformda kodlanmış uygulamalardır. meta katmanıdır ve zincir üstü mantığın (smart contracts) yanı sıra çeşitli blockchains ve mevcut zincir dışı arasındaki zincir dışı hesaplama ve bağlantıyı örtülü olarak kapsar hizmetler. Dil ve derleyici desteğine olan ihtiyaç göz önüne alındığında, yeni güvenlik modelleri ve farklı teknolojilerin kavramsal ve teknik uyumlaştırılması, ancak gerçekleştirilmesi Gerçek bir merkezi olmayan meta katmanının geliştirilmesi, uzun süredir arzuladığımız iddialı bir hedeftir. zaman ufku. Yine de okurken akılda tutulması gereken yararlı ve ideal bir modeldir. Bu makale, burada ayrıntıları verilmemiştir ancak gelecekteki çalışmalarımızda odaklanmayı planladığımız bir konudur. Chainlink. Ölçeklendirme: Gelişen tasarımlarımızda çok önemli bir hedef, Chainlink ağı, blockchain ekosisteminin artan ölçeklendirme ihtiyaçlarını karşılayacak. Ağ tıkanıklığının mevcut izinsiz uygulamalarda tekrar eden bir sorun haline gelmesiyle blockchains [86], yeni ve daha performanslı blockchain tasarımlar kullanıma giriyor, ör., [103, 120, 203] ve ayrıca tamamlayıcı katman-2 ölçeklendirme teknolojileri, ör., [5, 12, 121, 141, 169, 186, 187]. Oracle hizmetlerinin gecikmelere ve aktarım hızlarına ulaşması gerekiyor zincir içi ücretleri en aza indirirken bu sistemlerin performans taleplerini karşılayan (örneğin gaz maliyetleri) hem sözleşmeli operatörler hem de sıradan kullanıcılar için. DONs, Chainlink ile işlevsellik daha da ileri gitmeyi ve tamamen web tabanlı sistemler için yeterince yüksek performans sunmayı amaçlamaktadır. DON'ler performans kazanımlarının çoğunu blockchain'lerle birleştirdikleri hızlı, komite tabanlı veya izinsiz fikir birliği protokollerini kullanmalarından elde eder destekliyorlar. Farklı yapılandırmalara sahip birçok DON'nin paralel çalışmasını bekliyoruz; farklı DApp'ler ve kullanıcılar temel mutabakat tercihlerindeki ödünleşimlerde gezinebilir başvuru gereksinimlerine göre. DONs aslında katman 2 teknolojileri olarak görülebilir. arasında bunu bekliyoruz diğer hizmetler, DONs, İşlem Yürütme Çerçevesini (TEF) destekleyecektir. DONs'nin ve dolayısıyla oracles'nin diğer yüksek performanslı cihazlarla verimli entegrasyonunu kolaylaştırır katman-2 sistemleri—ör. rollups, işlemleri gerçekleştirmek için zincir dışı işlemleri bir araya getiren sistemler performans iyileştirmeleri. TEF'i Bölüm 6'da tanıtıyoruz.

Şekil 3: Merkezi olmayan bir meta katmanın ideal gerçekleştirilmesini gösteren kavramsal şekil. için Geliştirme kolaylığı için bir geliştirici, pembe renkle vurgulanan bir DApp'i sanal uygulama olarak belirtir. Birleşik bir makine modelinde uygulama. Merkezi olmayan bir meta katman derleyicisi otomatik olarak karşılık gelen birlikte çalışma işlevlerini üretir: smart contracts (belirtilen DONs üzerindeki mantık (exec ile gösterilir), hedef harici hizmetlere bağlanan bağdaştırıcılar vb., sarı renkte vurgulandığı gibi. Şekil 4, DONs'nin blockchain (smart contract) ölçeklendirmesini nasıl iyileştirdiğini kavramsal olarak göstermektedir işlem ve oracle-rapor işlemeyi zincir dışında yoğunlaştırarak zincir. Ana hesaplama odağındaki bu değişiklik, işlem gecikmesini azaltır ve işlem verimini artırırken ücretler. Gizlilik: Blok zincirleri, smart contract'ler ve gerçekleştirdikleri uygulamalar için benzeri görülmemiş bir şeffaflık sağlar. Ancak şeffaflık ile gizlilik arasında temel bir gerilim vardır. Örneğin bugün, kullanıcıların merkezi olmayan borsa aktarımlarıŞekil 4: Merkezi Olmayan Oracle Ağlarının merkezi olmayan Oracle Ağlarını nasıl iyileştirdiğini gösteren kavramsal şekil blockchain-etkin smart contracts'nin ölçeklendirilmesi. Şekil A ⃝geleneksel bir oracle gösterir Mimarlık. İşlemler, oracle raporlarında olduğu gibi doğrudan blockchain'ye gönderilir. Bu nedenle, sarı renkle vurgulanan blockchain, işlem gerçekleştirmenin ana odağıdır. Şekil B⃝, blockchain üzerindeki sözleşmeleri desteklemek için DON kullanımını göstermektedir. bir DON yürütülebilir dosya, işlemleri harici sistemlerden ve iletmelerden gelen verilerle birlikte işler sonuçları (örneğin, toplu işlemler veya işlemlerin etkilerinden kaynaklanan sözleşme durumu değişiklikleri) blockchain'ye aktarır. Sarı renkle vurgulanan DON bu nedenle ana işlem işlemenin yeri. Eylemler zincire kaydedilir, bu da değişim davranışını izlemeyi kolaylaştırır, aynı zamanda Kullanıcıların finansal işlemlerini kamuya açık hale getirmek. Benzer şekilde akıllılara iletilen veriler sözleşmeler zincirde kalıyor. Bu, bu tür verileri rahatlıkla denetlenebilir hale getirir, ancak aynı zamanda smart contracts'ye hassas veya hassas bilgiler sağlamak isteyen veri sağlayıcıları için caydırıcı özel veriler. oracle ağlarının yeni neslin katalizörlüğünde önemli bir rol oynayacağına inanıyoruz blockchains'nin doğuştan gelen şeffaflığını yeni gizlilik korumalarıyla birleştiren sistemler. Bu yazıda, üç ana yaklaşımı kullanarak bunu nasıl yapacaklarını gösteriyoruz: • Gizliliği koruyan adaptörler: Planlı dağıtıma sahip iki teknoloji Chainlink ağlarında, DECO [234] ve Town Crier [233], oracle düğümlerinin Kullanıcı gizliliğini ve verilerini koruyacak şekillerde zincir dışı sistemlerden veri almak gizlilik. DONs adaptörlerinin tasarımında önemli bir rol oynayacaklar. (Bu iki teknolojiye ilişkin ayrıntılar için Bölüm 3.6.2'ye bakın.) • Gizli hesaplama: DONs, hesaplamalarını blockchains'ye güvenmekten gizleyebilir. Güvenli çok taraflı hesaplama ve/veya güvenilir yürütme ortamları kullanılarak, DON düğümlerin bulunduğu daha güçlü bir gizlilik de mümkündür. kendilerinin görünür olmadığı veriler üzerinden işlem yapar.

• Gizli katman-2 sistemleri desteği: TEF, birçoğu sağlamak için sıfır bilgi kanıtlarını kullanan çeşitli katman-2 sistemlerini desteklemek üzere tasarlanmıştır. işlem gizliliğinin çeşitli biçimleri. Bu yaklaşımları Bölüm 3'te tartışıyoruz (Bölüm 6, Ek B.1 ve Ek B.2'de ek ayrıntılarla birlikte). Şekil 5, gizliliği koruyan adaptörler aracılığıyla harici kaynaklardan smart contract'ye hassas verilerin nasıl akabileceğine dair kavramsal bir görünüm sunar ve DON dosyasında gizli hesaplama. Şekil 5: DON adresindeki gizliliği koruyan işlemlerin kavramsal diyagramı hassas veriler (sarı renkle vurgulanmıştır). Web'deki hassas kaynak verileri (siyah daireler) sunucular gizliliği koruyan bağdaştırıcılar (mavi, çift oklu çizgiler) kullanılarak DON'ye çıkarılır. DON bu bağdaştırıcılardan türetilmiş verileri (içi boş daireler) alır— hassas kaynağa bir işlevin veya örneğin sır paylaşımının uygulanmasının sonucu veri. DON üzerindeki bir yürütülebilir dosya, türetilmiş verilere gizli hesaplama uygulayabilir bir adaptör üzerinden blockchain'ye göndereceği bir rapor (çift daire) oluşturmak için. Gizli verileri işlemeye yönelik güçlü araçların bir bütünün önünü açacağına inanıyoruz. uygulama yelpazesi. Bunlar arasında özel merkezi olmayan (ve merkezi) finans, merkezi olmayan kimlik, krediye dayalı zincirleme krediler ve daha verimli ve Bölüm 4'te tartıştığımız gibi kullanıcı dostu müşterini tanı ve akreditasyon protokolleri. İşlemler için sipariş adaleti: Bugünün blockchain tasarımlarında biraz kirli var Açık sır: Geçici olarak merkezileştirilmiştir. Madenciler ve validator'lar aktarım siparişi verebilirnasıl seçerlerse öyle hareket ederler. İşlem emri kullanıcılar tarafından da manipüle edilebilir. ödedikleri ağ ücretlerinin bir fonksiyonu (örneğin, Ethereum'deki gaz fiyatları) ve bazılarına hızlı ağ bağlantılarından yararlanarak. Bu tür bir manipülasyon, Örneğin, madenci gibi stratejik bir aktörün önden koşma biçimini alın. Bir kullanıcının işlemini gözlemler ve kendi yararlanma amaçlı işlemini daha önceki bir işleme ekler. aynı blokta konumlanma - kullanıcının işlemine ilişkin ileri bilgiden yararlanarak kullanıcıdan etkili bir şekilde para çalmak. Örneğin bir bot satın alma emri verebilir bir kullanıcıdan önce. Daha sonra bu durumun neden olduğu varlık fiyatı artışından faydalanabilir. kullanıcının ticareti. Sıradan kullanıcılara zarar veren bazı botlar tarafından önden çalıştırılıyor (yüksek frekansa benzer şekilde) Wall Street'te alım satım yapmak zaten yaygındır ve ilgili olduğu gibi [90] iyi belgelenmiştir [159] geri çalıştırma ve [195] taklit eden otomatik işlem gibi saldırılar. Madencilerin sipariş istismarını sistematik hale getirmeye yönelik öneriler yakın zamanda ortaya çıktı [110]. rollups gibi Katman 2 teknolojileri sorunu çözmez, yalnızca yeniden merkezileştirir rollup oluşturan varlığın eline vererek sipariş verir. Hedeflerimizden biri Chainlink'e Adil Sıralama adı verilen bir hizmeti tanıtmaktır. Hizmetler (FSS) [137]. FSS, smart contract tasarımcıların adil sipariş vermelerine yardımcı oluyor işlemlerini gerçekleştirin ve kullanıcı işlemlerinin yanı sıra oracle rapor iletimi gibi diğer işlem türlerine yönelik önden çalıştırma, geri çalıştırma ve ilgili saldırılardan kaçının. FSS DON'nin [144]'de tanıtılan kesin, geçici adalet kavramı gibi fikirleri uygulamasını sağlar. FSS, tesadüfi bir fayda olarak kullanıcıların ağını da düşürebilir ücretler (örneğin gaz maliyetleri). Kısaca, FSS'de işlemler doğrudan smart contract hedefine yayılmak yerine DON üzerinden geçer. DON işlemleri emreder ve ardından iletir sözleşmeye bağladılar. Şekil 6: FSS'nin ne kadar faydalı olduğuna dair örnek. Şekil A ⃝bir madencinin kendi gücünden nasıl yararlandığını gösterir işlemleri sipariş etme yetkisi, bir çift işlemi takas edebilir: işlem 1⃝ 2⃝'den önce gelir, ancak madenci bunu 2⃝'den sonra sıralar. Buna karşılık, Şekil B⃝göstermektedir DON'nin sipariş sürecini DON düğümleri arasında nasıl merkezileştirmediğini. Yeterli çoğunluk ise dürüst düğümler 2⃝'den önce 1⃝ alır, FSS zincirde 1⃝'nin 2⃝'den önce görünmesine neden olur— Sözleşmenin uygulanabilir sıra numaralarını ekleyerek madencinin yeniden sıralamasını önleme. Şekil 6, standart madenciliği FSS ile karşılaştırmaktadır. Standart madencilikte nasıl olduğunu gösterir,işlem siparişi süreci madencide merkezileştirilmiştir ve dolayısıyla bir çift işlemin gelişlerine göre yeniden sıralanması gibi manipülasyon kez. Bunun aksine, FSS'de süreç DON düğümleri arasında dağıtılmıştır. Varsayarak Dürüst düğümlerden oluşan bir yeter sayı ile FSS, düğümlerin zamansal olarak sıralanması gibi politikaların uygulanmasına yardımcı olur. Madenciler ve diğer kuruluşların manipülasyon fırsatlarını azaltarak işlemler. Ek olarak, kullanıcıların gaz fiyatına dayalı tercihli sipariş için rekabet etmelerine gerek olmadığından, nispeten düşük gaz fiyatları ödeyebilirler (DON'den yapılan işlemler toplu olarak yapılabilir) gaz tasarrufu için). Güven minimizasyonu: DONs tasarımındaki genel amacımız son derece kolay bir smart contracts ve diğer oracle bağımlı sistemler için güvenilir destek katmanı merkeziyetsizlik, kriptografik araçlar ve kriptoekonomik garantiler aracılığıyla. DON merkezi olmayan bir yapıya sahiptir ve kullanıcılar mevcut herhangi bir DON arasından seçim yapabilirler. üzerinde çalışmak veya ek DONs oluşturmak istedikleri ana zinciri destekler güvendikleri düğümlerden oluşan komitelerle. Ancak bazı uygulamalar için, özellikle smart contracts, Chainlink kullanıcıları DON tarafından desteklenen ana zinciri daha güvenilir olarak ele alan bir güven modelini tercih edin DON'nın kendisinden daha. Bu tür kullanıcılar için halihazırda bu uygulamaya dahil etmeyi planlıyoruz veya planlıyoruz. Chainlink ağının mimarisi, sözleşmelere olanak tanıyan bir dizi mekanizmaya sahiptir DONs tarafından sağlanan güvenlik güvencelerini güçlendirmek için ana zincirde aynı zamanda veri kaynaklarının bozulması olasılığına karşı korumaları da güçlendiriyor DON'nin verileri aldığı web sunucuları gibi. Bu mekanizmaları Bölüm 7'de açıklıyoruz. Bunlar beş ana başlık altında toplanıyor: • Veri kaynağı kimlik doğrulaması: Veri sağlayıcıların dijital olarak imza atmasına olanak tanıyan araçlar verilerini saklar ve böylece menşe ile kaynak arasındaki gözetim zincirini güçlendirir. güvenen sözleşme. • DON azınlık raporları: DON düğümlerinin azınlık alt kümesi tarafından yayınlanan bayraklar DON'de çoğunluğun görevini kötüye kullandığını gözlemliyor. • Koruma rayları: Anormal koşulları ve duraklamaları tespit eden ana zincirdeki mantık veya sözleşmenin yürütülmesini durdurur (veya diğer iyileştirmelere başvurur). • Güveni en aza indirilmiş yönetişim: Topluluk denetimini kolaylaştırmak için kademeli olarak yayınlanan güncellemelerin yanı sıra hızlı bir şekilde merkezi olmayan acil durum müdahalelerinin kullanılması Sistem arızalarına yanıt. • Merkezi olmayan varlık kimlik doğrulaması: Genel anahtar altyapısının (PKI) kullanımı Chainlink ağındaki varlıkları tanımlayın. Şekil 7, güveni en aza indirme hedeflerimizin kavramsal şemasını sunmaktadır. Teşvik tabanlı (kriptoekonomik) güvenlik: Rapor oluşturmanın oracle düğümler arasında merkezi olmaması, bazı düğümler bozulduğunda bile güvenliğin sağlanmasına yardımcı olur.

Şekil 7: Chainlink'in güveni en aza indirme hedefinin kavramsal tasviri: kullanıcıların DON ve web gibi veri kaynaklarının doğru davranışına olan ihtiyacını en aza indirin sunucular. Şekildeki sarı vurgular güvenin en aza indirildiği yerleri göstermektedir: DON ve bireysel veya azınlık web sunucuları kümeleri. Pembe vurgular sistem bileşenlerini gösterir Varsayım açısından oldukça güvenilir olan: blockchain ve çoğunluk sözleşmeleri web sunucularının toplamı, yani toplam web sunucuları. Ancak aynı derecede önemli olan, düğümlerin doğru davranmak için mali teşvike sahip olmasını sağlamaktır. Staking, yani düğümlerin LINK depozitosu sağlamasını gerektirme ve kesme Uygunsuz davranış durumunda bu mevduatlara el konulması (el konulması), Chainlink konusunda önemli bir rol oynayacaktır. Bu, halihazırda birçok blockchains'de kullanılan önemli bir teşvik tasarımıdır. örneğin, [81, 103, 120, 204]. Ancak Chainlink'de stake yapmak, tek başına staking'den çok farklı görünüyor blockchains. blockchains'de stake yapmak, fikir birliğine yönelik saldırıları önlemeyi amaçlamaktadır. Bir Chainlink'de farklı hedef: Doğru oracle raporların zamanında teslim edilmesini sağlamak. oracle ağı için iyi tasarlanmış bir staking sistemi, rüşvet gibi saldırılar gerçekleştirmelidir hedef yüksek değere sahip bir smart contract olsa bile rakip için kârlı değil parasal değer. Bu yazıda, Chainlink içindeki staking'ye üç anahtarla genel bir yaklaşım sunuyoruz. yenilikler:1. Mevcut sistemlerde gözden kaçan saldırıları kapsayan güçlü bir düşman modeli yaklaşımlar. Bunun bir örneği olası rüşvet olarak adlandırdığımız durumdur. Bu bir biçim Hangi düğümlerin koşullu olarak rüşvet alacağını belirleyen rüşvet; staking mekanizmasının seçtiği düğümlere önceden garantili rüşvet teklif eder belirli roller için rastgele (rapor kararının tetiklenmesi gibi). 2. Süper doğrusal staking etkisi; gayri resmi olarak, başarılı olmak için bir rakibin bütçesinin, tüm oracle mevduatlarının toplamından B $ daha fazla olması gerektiği anlamına gelir. düğümler. Daha doğrusu, n'nin bir fonksiyonu olarak \(B(n) ≫\)dn'nin bir a'da olduğunu kastediyoruz. her biri sabit $d depozito miktarına sahip n oracle düğümden oluşan ağ (daha resmi olarak, \(B(n) is asymptotically larger in n than \)dn). Şekil 8'de kavramsal bir görünüm verilmektedir. bu mülk. 3. Örtülü Teşvik Çerçevesi (IIF), tasarladığımız bir teşvik modeli açıkça yatırılanın ötesinde ampirik olarak ölçülebilir teşvikleri kapsar staking Düğümlerin gelecekteki ücret fırsatları da dahil olmak üzere fonlar. IIF kavramını genişletiyor Açık düğüm yatırmalarının ötesinde hisse. Şekil 8: Chainlink staking'de süper doğrusal ölçeklendirmeyi gösteren kavramsal diyagram. Rakibin ihtiyaç duyduğu rüşvet $B(n) miktarı, n cinsinden mevduatların toplamından daha hızlı artıyor Tüm oracle düğümlerin $dn'si. IIF ve süper doğrusal staking etkisinin birlikte nasıl sonuç verdiğini gösteriyoruz. oracle ağları için verimli bir ekonomik güvenlik döngüsü çağırın. Yeni kullanıcılar girdiğinde

sistem, Chainlink düğümlerini çalıştırmanın gelecekteki potansiyel kazançlarını artırarak, Mevcut ve gelecekteki kullanıcılar için ekonomik güvenliğin marjinal maliyeti düşer. bir rejimde Esnek talep nedeniyle bu azalan maliyet, ek kullanıcıları bu hizmetten yararlanmaya teşvik eder. devam eden verimli bir döngüde benimsenmeyi sürekli olarak sürdüren bir ağ. Not: Bu teknik inceleme, Chainlink'nın gelişimiyle ilgili vizyonumuzun önemli unsurlarını ana hatlarıyla özetlese de resmi değildir ve birkaç ayrıntılı teknik özellik içerir. Planlıyoruz Ek özellikler ve yaklaşımlar geliştikçe bunlara odaklanan teknik makaleler yayınlayın. Ayrıca, sunulan vizyonun birçok unsurunun da vurgulanması önemlidir. burada (ölçeklendirme iyileştirmeleri, gizlilik teknolojileri, FSS vb.) yapılabilir ve olacaktır. gelişmiş DON'ler temel bir özellik haline gelmeden önce bile ön formda dağıtıldı Chainlink. 1.3 Bu Makalenin Organizasyonu Güvenlik modelimizi ve gösterimimizi Bölüm 2'de sunacağız ve Merkezi Olmayan Sistemin ana hatlarını çizeceğiz. Bölüm 3'te Oracle Network API. Bölüm 4'te, Oracle Network API'nin bir dizi örneğini sunuyoruz. DONs'nin ilgi çekici bir dağıtım platformu sağladığı uygulamalar. Okuyucular şunları yapabilir: Bu noktaya kadar okuyarak makaledeki temel kavramların çoğunu öğrenin. Makalenin geri kalan kısmı daha fazla ayrıntı içermektedir. Adil Sıralamayı anlatıyoruz Bölüm 5'te Hizmetler (FSS) ve Bölüm 6'da İşlem Yürütme Çerçevesi (TEF). Bölüm 7'de güven minimizasyonuna yönelik yaklaşımımızı açıklıyoruz. önemli DON dağıtım gereksinimleri, yani özelliklerin artımlı olarak kullanıma sunulması, dinamik defter üyeliği ve Bölüm 8'deki hesap verebilirlik. Son olarak Bölüm 9'da şunları veriyoruz: Teşvik tasarımına yönelik gelişen yaklaşımımıza genel bir bakış. Bölüm 10'da bitiriyoruz. Bu makaledeki kavramlara sınırlı aşinalığı olan okuyuculara yardımcı olmak için, Ek A'da bir sözlük sunuyoruz. DON arayüzünde daha fazla ayrıntı sunuyoruz ve işlevsellik Ek B'de ve bazı örnek bağdaştırıcılar Ek C'de sunulmaktadır. Ek D'de güveni en aza indirilmiş veri kaynağı için bir şifreleme ilkesini açıklıyoruz kimlik doğrulama, işlevsel imzalar olarak adlandırılır ve ayrıklaştırılmış işlevsel imzalar adı verilen yeni bir değişken sunar. Komiteyle ilgili bazı hususları tartışıyoruz Ek F'deki DONs seçimi.

Güvenlik Modeli ve Hedefleri

Merkezi Olmayan Oracle Ağı, farklı bir dağıtılmış sistem olup, Başlangıçta, zorunlu olmasa da tipik olarak komite temelli bir kuruluş tarafından uygulanmalıdır. fikir birliği protokolüdür ve bir dizi oracle düğüm tarafından çalıştırılır. Bir DON öncelikle tasarlanmıştır oracle raporlarıyla ana zincirdeki smart contract'nin yeteneklerini artırmak için ve diğer hizmetler, ancak aynı destek hizmetlerini blockchain olmayan diğer sistemlere de sağlayabilir ve dolayısıyla belirli bir ana zincirle ilişkilendirilmesine gerek yoktur.

Dolayısıyla ele aldığımız model ve özellikler, kullanımdan büyük ölçüde bağımsızdır. DON'nin belirli uygulamaları. 2.1 Güncel Mimari Model Bugün Chainlink'nin yekpare bir hizmet olmadığını, bunun yerine farklı, bağımsız başlatmanın mümkün olduğu izinsiz bir çerçeve oracle düğümlerin ağları [77]. Ağlar heterojen düğüm operatörlerine sahiptir ve tasarımlar. Sağladıkları hizmet türleri açısından da farklılık gösterebilirler. örneğin veri beslemeleri, Rezerv Kanıtı, doğrulanabilir rastgelelik vb. içerir. Diğer Farklılıklar arasında merkeziyetsizlik derecesi, ağ boyutu ve desteklediği kilitli değer ve veri frekansı gibi çeşitli hizmet düzeyi parametreleri ve doğruluk. Chainlink'in izinsiz modeli, bir ekosistemin büyümesini teşvik eder. sağlayıcılar topluma en iyi şekilde sunabilecekleri hizmetlerde uzmanlaşırlar. Bu modelin, kullanıcılara daha düşük maliyet ve bir modele göre daha yüksek hizmet kalitesi sağlaması muhtemeldir tüm düğümlerin ve ağların eksiksiz bir hizmet yelpazesi sunmasını gerektiren bir yaklaşım en az temsil eden hizmetlerin sistem çapında benimsenmesine kolaylıkla devredilebilir. düğümlerin kullanabileceği kaynakların ortak paydası. Chainlink, Chainlink 2.0'da DON tabanlı tasarımlara doğru geliştikçe, biz de amacını göz önünde bulundurarak izinsiz, açık bir çerçeve modelini destekleyin kullanıcılara küresel olarak en iyi eşleşmeyi sağlayan çeşitli hizmet seçenekleri sunmak özel uygulama gereksinimleri ile. 2.2 Konsensüs Varsayımları Merkezi Olmayan Oracle Ağı terimini, tam işlevselliğini kapsamak için kullanıyoruz. tanımladığımız oracle sistemi: hem oracle düğümlerinin sürdürdüğü veri yapısı hem de çekirdek API bunun üzerine yerleştirildi. Temel verileri ifade etmek için L ile gösterilen defter (küçük harf) terimini kullanırız. DON tarafından sürdürülen ve sağladığı belirli hizmetleri desteklemek için kullanılan yapı. DON çerçevemizin L'yi bağımsız bir sistem olarak ele almadığını vurguluyoruz a blockchain: Amacı blockchains ve diğer sistemleri desteklemektir. Blockchainler, Elbette güvenilir bir defter tutmanın bir yolu, ama başka yollar da var. Bekliyoruz DONs çoğu durumda temel defterlerini Bizans Hata Toleranslı kullanarak gerçekleştirmek için (BFT) sistemleri, Bitcoin [174] gibi blockchain'lerden oldukça öncesine aittir. Kullanıyoruz BFT-yazının tamamında kolaylık olması açısından notasyon ve özellikleri yazın, ancak biz DON'lerin izinsiz fikir birliği protokolleri kullanılarak gerçekleştirilebileceğini vurgulayın. Kavramsal olarak L defteri, verilerin doğrusal olarak sıralandığı bir ilan tahtasıdır. Genel olarak bir defterin, genel olarak kendisine atfedilen birkaç temel özelliğe sahip olduğunu düşünüyoruz. blockchains [115]. Bir defter: • Yalnızca ekleme: Veriler bir kez eklendikten sonra kaldırılamaz veya değiştirilemez.• Genel: Zaman içinde tutarlı olan içeriğini herkes okuyabilir. tüm kullanıcıların görünümü.4 • Mevcut: Deftere her zaman yetkili yazarlar tarafından yazılabilir ve okunabilir herhangi biri tarafından zamanında. Bir DON tarafından gerçekleştirildiğinde defterde alternatif özellikler mümkündür. komite. Örneğin, genel muhasebeye yazma erişimi belirli kullanıcılarla sınırlı olabilir; bazı uygulamalar için okuma erişimi olabilir, yani defterin tanımlandığı gibi herkese açık olması gerekmez yukarıda. Benzer şekilde, genel muhasebe kuralları verilerin değiştirilmesine veya düzeltilmesine izin verebilir. Biz yapmıyoruz ancak bu yazıda bu tür değişkenleri açıkça değerlendirin. DONs modüler tasarımı, çok çeşitli modern BFT modellerinden herhangi birini destekleyebilir protokoller, örneğin Hotstuff[231]. Kesin seçim güven varsayımlarına bağlı olacaktır ve oracle düğümleri arasındaki ağ özellikleri. Bir DON prensipte alternatif olarak kullanılabilir destekleyen rolünde defteri defteri için yüksek performanslı, izinsiz bir blockchain kullanın. eşit şekilde ölçeklenebilir katman-2 veya blockchain sistemi. Benzer şekilde hibridizasyon da mümkündür: DON prensip olarak mevcut bir ağdaki validators olan düğümlerden oluşabilir. blockchain, örneğin komitelerin yürütmek üzere seçildiği Proof-of-Stake sistemlerinde işlemler, örneğin, [8, 81, 120, 146, 204]. Bu özel çalışma modu şunları gerektirir: düğümler çift kullanımlı bir şekilde çalışır; yani hem blockchain düğüm hem de DON olarak çalışır. düğümler. (Değişimde sürekliliği sağlamaya yönelik tekniklerin tartışılması için Bölüm 8.2'ye bakın.) Rastgele komite seçimiyle ilgili bazı uyarılar için komiteler ve Ek F'de yer almaktadır.) Uygulamada, modern BFT algoritmalarında, düğümler defterdeki mesajları dijital olarak imzalar. Kolaylık sağlamak için L'nin ilişkili bir genel anahtar pkL'ye sahip olduğunu ve içeriğinin karşılık gelen özel anahtarla imzalanır. Bu genel gösterim aşağıdaki durumlarda bile geçerlidir: L'deki veriler eşik imzaları kullanılarak imzalanır.5 Eşik imzaları uygundur, üyelik değişikliklerinde bile DON için kalıcı bir kimlik sağladıklarından onu çalıştıran düğümler. (Bkz. Ek B.1.3.) Dolayısıyla skL'nin gizli olarak paylaşıldığını varsayıyoruz. bazı güvenlik parametresi k için (k, n)-eşik tarzında, örneğin k = 2f + 1 ve n = 3f + 1; burada f, potansiyel olarak hatalı düğümlerin sayısıdır. (Bunda k'yi seçerek Bu şekilde, hatalı düğümlerin ne skL'yi öğrenebilmesini ne de hizmet reddi uygulayamamasını sağlıyoruz kullanımını engelleyen saldırı.) L'deki bir mesaj M = (m, z) formunu alır; burada m bir dize ve z benzersizdir. sıralı indeks numarası Mümkün olduğunda mesajları m = biçiminde yazarız. ⟨Mesaj Türü: yük⟩. Mesaj türü Mesaj Türü, belirli bir mesajın işlevini belirten sözdizimsel şekerdir. 4Sonu olmayan bir blockchain'nin bir defteri gerçekleştirdiği durumlarda tutarsızlık genellikle soyutlanır Yeterince derin olmayan blokları göz ardı ederek veya "budayarak" [115]. 5Uygulamada, Hotstuff'ın bir çeşidi olan LibraBFT [205] gibi bazı kod tabanları şu anda benimsenmiştir eşik imzalar yerine çoklu imzalar, azaltılmış iletişim karmaşıklığını ortadan kaldırır daha basit mühendislik. Bir miktar ek maliyetle, oracle düğümleri iletilere eşik imzaları ekleyebilir L için kullanılan konsensüs protokolü bunları kullanmasa bile L'ye yazılır.2.3 Gösterim Defteri çalıştıran n oracle düğüm kümesini O = {Oi}n ile gösteririz ben=1. Böyle bir düğümler kümesine genellikle komite adı verilir. Basitlik açısından, kümesinin olduğunu varsayıyoruz. oracles'nin DON işlevselliğini uygulaması, yani L'nin üzerindeki hizmetler, ile aynıdır L'yi koruyan, ancak farklı olabilirler. Pki'nin genel anahtarını belirtmesine izin veriyoruz Oi oyuncusuna gidin ve ilgili özel anahtarı girin. Çoğu BFT algoritması en az n = 3f + 1 düğüm gerektirir; burada f, düğümlerin sayısıdır potansiyel olarak hatalı düğümler; Geriye kalan düğümler, kuralları takip etmeleri anlamında dürüsttür. protokolü tam olarak belirtildiği gibi kullanın. Eğer bu koşulları karşılıyorsa O komitesine dürüst diyoruz. gereksinim, yani dürüst düğümlerin 2/3 oranından daha fazlasına sahip olması. Aksi sürece belirtildiği gibi, O'nun dürüst (ve statik bir yolsuzluk modeli) olduğunu varsayıyoruz. pkO / kullanıyoruz skO, bağlama bağlı olarak pkL / skL ile değiştirilebilir. σ = Sigpk[m]'in m mesajındaki pk'ye göre bir imzayı gösterdiğine izin veririz, yani şunu kullanırız: karşılık gelen özel anahtar sk. doğrulama(pk, σ, m) →{yanlış, doğru}'nun karşılık gelen imza doğrulama algoritmasını gösterdiğine izin verin. (Anahtar oluşturmayı makale boyunca örtülü bırakıyoruz.) Bir veri kaynağını belirtmek için S gösterimini ve verilerin tam kümesini belirtmek için S gösterimini kullanırız. Belirli bir bağlamda nS kaynakları. MAINCHAIN ile akıllı sözleşmenin etkin olduğunu belirtiyoruz blockchain, DON tarafından destekleniyor. Herhangi bir akıllıyı belirtmek için güvenilen sözleşme terimini kullanıyoruz. DON ile iletişim kuran MAINCHAIN üzerindeki sözleşme ve SC gösterimini kullanarak böyle bir sözleşmeyi belirtir. Genel olarak bir DON'nin tek bir ana zincir ANA ZİNCİR'i desteklediğini varsayarız, ancak Bölüm 4'teki örneklerde gösterdiğimiz gibi birden fazla zinciri destekleyebilir. DON MAINCHAIN üzerinde birden fazla bağımlı sözleşmeyi destekleyebilir ve genellikle destekleyecektir. (olarak yukarıda belirtildiği gibi, DON alternatif olarak blockchain olmayan hizmetleri de destekleyebilir.) 2.4 Güven Modellerine İlişkin Not Yukarıda belirtildiği gibi, DON'ler komite tabanlı konsensüs protokolleri üzerine oluşturulabilir ve biz Bu tür protokolleri yaygın olarak kullanacaklarını umuyoruz. Buna dair pek çok güçlü argüman var Komite tabanlı veya izinsiz blockchains olmak üzere iki alternatiften biri şunu sağlar: diğerinden daha güçlü güvenlik. Komite tabanlı güvenlik ile izinsiz güvenlik arasındaki farkı bilmek önemlidir. merkezi olmayan sistemler kıyaslanamaz. PoW veya PoS'un ele geçirilmesi blockchain %51 saldırısı yoluyla, düşmanın çoğunluk kaynaklarını geçici olarak ele geçirmesi ve potansiyel olarak anonim olarak, örneğin bir PoW sisteminde hash gücü kiralayarak. Böyle pratikteki saldırılar halihazırda birkaç blockchains'yi etkilemiştir [200, 34]. Buna karşılık, Komiteye dayalı bir sistemin tehlikeye atılması, düğümlerin kamuya açık olarak tanınabileceği, iyi kaynaklara sahip olabileceği, düğümlerinin eşik sayısını (genellikle üçte biri) bozmak anlamına gelir. ve güvenilir kuruluşlar. Öte yandan komite tabanlı sistemler (aynı zamanda “hibrit” izinsiz) Komiteleri destekleyen sistemler) katı bir şekilde uygulanandan daha fazla işlevselliği destekleyebilir.misyonsuz sistemler. Bu, aşağıdakiler gibi kalıcı sırları koruma yeteneğini de içerir: imzalama ve/veya şifreleme anahtarları; tasarımlarımızda bir olasılık. DON'lerin prensipte komite temelli veya izinsiz fikir birliği protokolü ve DON dağıtımcıları sonuçta bunu benimsemeyi seçebilir ya yaklaşın. Güven modellerinin güçlendirilmesi: Chainlink'in günümüzün en önemli özelliği, kullanıcıların tartışıldığı gibi performans geçmişlerinin merkezi olmayan kayıtlarına göre düğümleri seçin Bölüm 3.6.4'te. Bölüm 9'da tanıttığımız staking mekanizması ve Örtülü Teşvik Çerçevesi birlikte geniş kapsamlı ve titiz bir mekanizma tasarımı oluşturur Kullanıcılara DONs güvenliğini ölçme konusunda büyük ölçüde genişletilmiş bir yetenek sağlayacak bir çerçeve. Aynı çerçeve aynı zamanda DONs için de bunu mümkün kılacaktır. Katılımcı düğümlerde çeşitli güvenlik gereksinimlerini uygulamak ve çalışmayı sağlamak güçlü güven modelleri içinde. Düzenleme gerekliliklerine uygunluk gibi özel güven modeli gerekliliklerini uygulamak için DONs için bu belgede açıklanan araçları kullanmak da mümkündür. için Örneğin, Bölüm 4.3'te tartışılan teknikleri kullanarak, düğümler aşağıdakilerin kanıtını sunabilir: yardımcı olmak için kullanılabilecek düğüm operatörü özellikleri (ör. operasyon bölgesi) örneğin Genel Veri Koruma Yönetmeliği (GDPR) Madde 3 (“Bölgesel Kapsam”) [105] ile uyumluluğu sağlamak. Aksi takdirde bu tür bir uyumun sağlanması zor olabilir. merkezi olmayan sistemlerde buluşuyor [45]. Ayrıca Bölüm 7'de DONs'nin sağlamlığını güçlendirmeye yönelik planları tartışıyoruz. Destekledikleri ana zincirlerdeki güveni en aza indirme mekanizmaları aracılığıyla.

Merkezi Olmayan Oracle Ağ Arayüzü ve Ca-

yetenekler Burada DONs'nin yeteneklerini basit ama güçlü bir şekilde kısaca özetliyoruz. gerçekleştirmek için tasarlandıkları arayüz. DON üzerindeki uygulamalar yürütülebilir dosyalardan ve bağdaştırıcılardan oluşur. Yürütülebilir bir dosya çekirdek mantığı smart contract'ye benzeyen deterministik bir program olan bir program. Yürütülebilir bir dosyanın ayrıca bir dizi başlatıcısı, girişi çağıran programları vardır. önceden belirlenmiş olaylar meydana geldiğinde, örneğin belirli zamanlarda, yürütülebilir dosyanın mantığındaki noktalar (cron işi gibi), bir fiyat bir eşiği geçtiğinde vb. — Keepers'a çok benzer (bkz. Bölüm 3.6.3). Bağdaştırıcılar zincir dışı kaynaklara arayüzler sağlar ve yürütülebilir dosyalardaki başlatıcılar veya çekirdek mantık. Davranışları buna bağlı olabileceğinden Dış kaynakların, başlatıcıların ve bağdaştırıcıların belirleyici olmayan bir şekilde davranabilmeleri. DON geliştirici arayüzünü ve yürütülebilir dosyaların işleyişini açıklıyoruz ve bağdaştırıcıları genellikle bilgi işlem sistemlerini karakterize etmek için kullanılan üç kaynak açısından kullanır: ağ oluşturma, bilgi işlem ve depolama. Bunların her birine kısa bir genel bakış sunuyoruz Aşağıdaki kaynaklara bakın ve Ek B'de daha fazla ayrıntı sağlayın.

3.1 Ağ oluşturma Bağdaştırıcılar, DON üzerinde çalışan yürütülebilir dosyaların gönderilip gönderilebildiği arayüzlerdir. off-DON sistemlerden veri alın. Adaptörler bir genelleme olarak görülebilir. bugün Chainlink'de kullanılan bağdaştırıcılar [20]. Adaptörler çift yönlü olabilir; verileri yalnızca çekemez, ancak verileri DON adresinden bir web sunucusuna aktarır. Ayrıca yararlanabilirler dağıtılmış protokollerin yanı sıra güvenli çok taraflı şifreleme gibi şifreleme işlevleri hesaplama. Şekil 9: DON1 olarak adlandırılan DON'yı, DON2 olarak adlandırılan başka bir DON, bir blockchain (ana zincir) ve onun da dahil olduğu bir dizi farklı kaynağa bağlayan adaptörler bellek havuzu, harici depolama, bir web sunucusu ve IoT cihazları (bir web sunucusu aracılığıyla). Bağdaştırıcıların oluşturulabileceği harici kaynaklara örnekler gösterilmektedir Şekil 9'da. Bunlar şunları içerir: • Blok zincirleri: Bir bağdaştırıcı, işlemlerin blockchain'ye nasıl gönderileceğini tanımlayabilir ve blokların, bireysel işlemlerin veya diğer durumların nasıl okunacağı. Bir adaptör blockchain'nın bellek havuzu için de tanımlanabilir. (Bölüm 3.5'e bakınız.) • Web sunucuları: Bağdaştırıcılar, verilerin alınabileceği API'leri tanımlayabilir için özel olarak uyarlanmamış eski sistemler de dahil olmak üzere web sunucularından DONs ile arayüz oluşturuluyor. Bu tür bağdaştırıcılar ayrıca veri göndermek için API'ler de içerebilir. bu tür sunucular. DON'nin bağlandığı web sunucuları ağ geçidi görevi görebilir Nesnelerin İnterneti (IoT) cihazları gibi ek kaynaklara.• Harici depolama: Bir bağdaştırıcı, depolama birimine okuma ve yazma yöntemlerini tanımlayabilir merkezi olmayan dosya sistemi [40, 188] veya bulut gibi DON dışındaki hizmetler depolama. • Diğer DON'ler: Bağdaştırıcılar DON'ler arasında veri alabilir ve iletebilir. DON'lerin ilk dağıtımlarının bir dizi yapı taşı içermesini bekliyoruz bu tür yaygın olarak kullanılan harici kaynaklar için bağdaştırıcılar ve ayrıca DON'ya özel DON düğümleri tarafından yayınlanacak bağdaştırıcılar. smart contract geliştiriciler bağdaştırıcıları yazarken bugün bu gelişmiş teknolojiyi kullanarak çok daha güçlü adaptörler üretmelerini bekliyoruz. işlevsellik. Sonuçta kullanıcıların yeni bağdaştırıcılar oluşturmasının mümkün olacağını umuyoruz. izinsiz bir şekilde. Bazı bağdaştırıcılar, DON tarafından kontrol edilen dış kaynakların kalıcılığını ve kullanılabilirliğini sağlayacak şekilde oluşturulmalıdır. Örneğin bulut depolama bir bulut hizmetleri hesabının bakımını gerektirir. Ek olarak, bir DON işlemi gerçekleştirebilir Kullanıcılar adına özel anahtarların merkezi olmayan yönetimi (ör. [160] gibi) ve/veya yürütülebilir dosyalar Sonuç olarak, DON, örneğin blockchain hedefine işlem göndermek için kullanılabilecek kripto para birimi gibi kaynakları kontrol etme kapasitesine sahiptir. DON adaptörlerle ilgili daha fazla ayrıntı için Ek B.1'e, birkaç adaptör için Ek C'ye bakın. örnek adaptörler. 3.2 hesaplama Yürütülebilir dosya, DON üzerindeki temel kod birimidir. Yürütülebilir bir dosya çiftidir exec = (mantık, başlangıç). Burada mantık, bir dizi belirlenmiş girişe sahip deterministik bir programdır. noktalar (mantık1, mantık2,..., mantıkℓ) ve init karşılık gelen başlatıcıların bir kümesidir (init1, init2,..., inite). DON'nin tam denetlenebilirliğini sağlamak için bir yürütülebilir dosyanın mantığı tüm girdiler ve çıktılar için temel L defterini kullanır. Bu nedenle, örneğin herhangi bir adaptör Yürütülebilir bir dosyaya girdi görevi gören veriler ilk olarak L'de saklanmalıdır. Başlatıcılar: Bugün Chainlink'deki başlatıcılar olaya bağlı iş yürütmelerine neden oluyor Chainlink düğümler [21]. DONs içindeki başlatıcılar hemen hemen aynı şekilde çalışır. Bununla birlikte, bir DON başlatıcısı özellikle yürütülebilir bir dosyayla ilişkilendirilir. Bir başlatıcı bağlı olabilir harici bir olaya veya duruma, geçerli zamana veya DON durumuna ilişkin bir yüklem üzerinde. Olaylara bağımlılıkları nedeniyle, başlatıcılar elbette deterministik olmayan bir şekilde davranabilirler. (tabii ki adaptörler de olabilir). Bir başlatıcı, tek tek DON düğümlerde yürütülebilir ve bu nedenle bir adaptöre güvenmeniz gerekmez. (Aşağıdaki Örnek 1'e bakın.) Başlatıcılar, yürütülebilir dosyaları smart contract'lerden ayıran önemli bir özelliktir. Yürütülebilir bir dosya bir başlatıcıya yanıt olarak çalışabildiğinden, etkili bir şekilde çalışabilir. özerk olarak, elbette uzantı olarak yürütülebilir dosyayı içeren hibrit bir sözleşme olabilir. Günümüzdeki başlatıcılardan biri, işlem sağlayan Chainlink Bekçilerdir.oracle raporlarına dayanarak smart contract yürütmeyi tetikleyen (yetersiz teminatlandırılmış kredilerin tasfiyesi ve limit emri işlemlerinin yürütülmesi gibi) otomasyon hizmetleri. Uygun bir şekilde, DONs içindeki başlatıcılar aynı zamanda Bir yürütülebilir dosya için geçerli olan hizmet sözleşmeleri, aşağıdaki koşulları tanımladıkları için DON onu çağırmalı. Aşağıdaki örnek, başlatıcıların bir yürütülebilir dosyada nasıl çalıştığını göstermektedir: Örnek 1 (Sapmanın tetiklediği fiyat akışı). smart contract SC'nin yenilenmesi gerekebilir fiyat-besleme verileri (bkz. Bölüm 3.6.3) önemli bir değişiklik olduğunda (örneğin %1), ETH-USD gibi bir varlık çifti arasındaki döviz kuru. Volatiliteye duyarlı fiyat yayınlar bugün Chainlink tarafından desteklenmektedir, ancak bunların nasıl olabileceğini görmek öğreticidir yürütülebilir bir execfeed aracılığıyla DON üzerinde gerçekleştirildi. Yürütülebilir execfeed, L'deki en güncel ETH-USD fiyatını (r) korur. ⟨NewPrice : j, r⟩entries dizisinin biçimi; burada j, ile artan bir indekstir her fiyat güncellemesi. Başlatıcı init1, her Oi düğümünün mevcut ETH-USD fiyatını izlemesine neden olur. j endeksi ile en son saklanan r fiyatından en az %1 sapma. üzerine Böyle bir sapmanın tespit edilmesi durumunda Oi, yeni fiyatın mevcut görünümü Ri'yi kullanarak L'ye yazar. ⟨PriceView : i, j + 1, ri⟩ formunun girişi. Yeni fiyat içeren en az k adet PriceView girişi olduğunda ikinci bir başlatıcı init2 etkinleşir Farklı düğümler tarafından oluşturulan j + 1 indeksi için değerler L üzerinde birikmiştir. Daha sonra init2 ilk k yeni, geçerli fiyat görünümü değerinin medyanını ρ hesaplamak için bir giriş noktası mantığını2 çağırır ve yeni bir değer ⟨NewPrice : j + 1, ρ⟩to L'ye yazar. (Operasyonel olarak düğümler sırayla belirlenmiş yazarlar olarak görev alabilirler.) Üçüncü bir başlatıcı init3, L'deki NewPrice girişlerini izliyor. Ne zaman yeni bir rapor gelse ⟨YeniFiyat : j, r⟩burada belirir, (j, r)'yi SC'ye iten bir giriş noktası mantığını3 çağırır bir adaptör kullanarak. Belirttiğimiz gibi, yürütülebilir bir dosya yetenekleri açısından smart contract ile benzerdir. Daha yüksek performansının yanı sıra tipik bir ana zincir sözleşmesinden farklıdır. iki temel yolla: 1. Gizlilik: Bir yürütülebilir dosya, gizli hesaplama gerçekleştirebilir; yani gizli bir program, açık metin girişlerini işleyebilir veya yayınlanmış bir program, gizli metin girişlerini işleyebilir. gizli giriş verileri veya her ikisinin bir kombinasyonu. Basit bir modelde gizli veriler ara sonuçları gizleyen ve yalnızca ifşa eden DON düğümleri tarafından erişilebilir işlenmiş ve sterilize edilmiş değerleri MAINCHAIN'e aktarır. Hassas verileri DONs'nin kendisinden gizlemek de mümkündür: DONs'nin amacı şu tür yaklaşımları desteklemektir: çok partili hesaplama olarak, örneğin [42, 157] ve güvenilir yürütme ortamları (TEE'ler) [84, 133, 152, 229] bu amaç içindir.6 6Uzantı olarak, yürütülebilir dosyaların DON düğümlerine göre gizli tutulması da mümkündür, ancak bu bugün yalnızca TEE'leri kullanan önemsiz olmayan yürütülebilir dosyalar için pratiktir.2. Destekleyici rol: Bir yürütülebilir dosyanın ana sunucuda smart contracts'yi desteklemesi amaçlanır. değiştirmek yerine zinciri kullanın. Bir yürütülebilir dosyanın çeşitli sınırlamaları vardır. smart contract şunu yapmaz: (a) Güven modeli: Bir yürütülebilir dosya, tarafından tanımlanan güven modeli dahilinde çalışır. DON: Doğru şekilde uygulanması O.'nun dürüst davranışına bağlıdır (Ana Ancak zincir, DON suiistimallere karşı bazı koruma rayları sağlayabilir, çünkü Bölüm 7.3'te tartışılmıştır.) (b) Varlık erişimi: Bir DON, blockchain üzerindeki bir hesabı kontrol edebilir ve dolayısıyla Bir adaptör aracılığıyla üzerindeki varlıkları kontrol edin. Ancak DON yetkili olarak olamaz ana zincirde oluşturulan varlıkları temsil eder, örneğin Ether veya ERC20 tokens, çünkü yerel zincirleri, mülkiyetlerine ilişkin yetkili kayıtları tutar. (c) Yaşam Döngüsü: DONs, sınırlı ömürlerle kasıtlı olarak ayağa kaldırılabilir, çünkü DONs ve sahipler arasındaki zincir içi hizmet düzeyi anlaşmalarıyla tanımlanır sözleşmelere güvenmek. Blok zincirleri ise tam tersine şu şekilde işlev görmektedir: kalıcı arşivleme sistemleri. DON hesaplamasına ilişkin daha fazla ayrıntı için Ek B.2'ye bakın. 3.3 Depolama Komite tabanlı bir sistem olarak DON orta miktarda veriyi kalıcı olarak depolayabilir L'de izinsiz bir blockchain'den çok daha düşük maliyetle. Ayrıca adaptörler aracılığıyla DONs, veri depolama için harici merkezi olmayan sistemlere referans verebilir, örneğin Filecoin [85], ve böylece bu tür sistemleri smart contracts'ye bağlayabilir. Bu seçenek özellikle Yaygın "şişkinlik" sorununu çözmenin bir yolu olarak toplu veriler için çekici blockchain sistemler. DONs böylece, kendi özel olarak desteklenen hizmetlerinde kullanılmak üzere verileri yerel veya harici olarak depolayabilir. DON ayrıca bu tür verileri gizli bir şekilde kullanabilir, (1) DON düğümleri arasında gizli olarak paylaşılan veya altında şifrelenen veriler üzerinde işlem yapmak DON düğümleri tarafından güvenli çok taraflı hesaplamaya uygun yöntemlerle yönetilen bir anahtar veya kısmi veya tamamen homomorfik şifreleme; veya (2) güvenilir bir yürütme kullanılarak korunuyor çevre. DON'lerin ortak basit bir bellek yönetimi modelini benimsemesini bekliyoruz. akıllı sözleşme sistemleri: Bir yürütülebilir dosya yalnızca kendi belleğine yazabilir. Yürütülebilir dosyalar ancak diğer yürütülebilir dosyaların belleğinden de okunabilir. DON depolama hakkında daha fazla ayrıntı için Ek B.3'e bakın. 3.4 İşlem Yürütme Çerçevesi (TEF) DONs, bir ana zincirdeki (veya birden fazla ana zincirdeki) sözleşmeleri desteklemeyi amaçlamaktadır. İşlem Yürütme Çerçevesi (TEF) ayrıntılı olarak tartışılıyorBölüm 6'da, bir sözleşmenin etkin bir şekilde yürütülmesine yönelik genel amaçlı bir yaklaşım yer almaktadır. ANA ZİNCİR boyunca SC ve DON. TEF'in FSS'yi ve katman-2'yi desteklemesi amaçlanmaktadır. teknolojiler—istenirse aynı anda. Gerçekten de ana araç olarak hizmet vermesi muhtemeldir. FSS'nin kullanımı için (ve bu nedenle, bu bölümde FSS'yi daha fazla tartışmıyoruz). Kısaca TEF'te MAINCHAIN için tasarlanan veya geliştirilen orijinal bir hedef sözleşme SC Hibrit bir sözleşmeye yeniden düzenlendi. Bu yeniden düzenleme, birlikte çalışan iki öğeyi üretir Hibrit sözleşmenin parçaları: netlik sağlamak amacıyla başvurduğumuz bir ANA ZİNCİR sözleşmesi SCa TEF'ler bağlamında bir bağlantı sözleşmesi ve DON üzerinde yürütülebilir bir yönetici olarak. sözleşme SCa, kullanıcıların varlıklarını saklar, yetkili durum geçişlerini yürütür ve ayrıca DON arızalarına karşı koruma rayları sağlar (bkz. Bölüm 7.3). Yürütülebilir yöneticiler işlemleri sıralar ve bunlarla ilişkili oracle verilerini sağlar. Paketleyebilir SCa için çeşitli yollardan herhangi biriyle işlem yapın; örneğin, geçerlilik kanıtına dayalı veya iyimser rollups, DON tarafından gizli yürütme vb. Geliştiricilerin bir sözleşmeyi bölümlendirmesini kolaylaştıracak araçlar geliştirmeyi umuyoruz SC, üst düzey bir dilde MAINCHAIN ve DON mantığının parçalarına, SCa ve SCa'ya yazılmıştır. sırasıyla güvenli ve verimli bir şekilde oluşturan yöneticiler. Yüksek performanslı işlem şemalarını yüksek performanslı işlemlerle entegre etmek için TEF'i kullanma oracles, oracle ölçeklendirme yaklaşımımızın ayrılmaz bir parçasıdır. 3.5 Bellek Havuzu Hizmetleri Destek kapsamında DONs üzerinde dağıtmayı planladığımız önemli bir uygulama katmanı özelliği FSS ve TEF, Mempool Hizmetleridir (MS). MS bir adaptör olarak görülebilir, ama birinci sınıf desteği olan bir tane. MS, eski uyumlu işlem işleme için destek sağlar. Bu kullanımda MS Bir hedef sözleşmeye yönelik işlemleri ana zincirin bellek havuzundan alır MAINCHAIN'de SC. MS daha sonra bu işlemleri DON üzerinde yürütülebilir bir dosyaya aktarır, istenilen şekilde işlenirler. MS verileri DON tarafından kullanılabilir DON adresinden doğrudan SC'ye aktarılabilecek işlemleri oluşturmak veya SC'yi çağıran başka bir sözleşmeye. Örneğin, DON işlemleri iletebilir MS aracılığıyla toplanır veya gönderdiği işlemler için gaz fiyatlarını ayarlamak üzere MS verilerini kullanabilir. ANA ZİNCİR. Bellek havuzunu izlediği için MS, SC ile doğrudan etkileşimde bulunan kullanıcılardan işlemleri alabilir. Böylece kullanıcılar işlemlerini kullanarak oluşturmaya devam edebilirler. eski yazılımlar, yani MS'in varlığından habersiz ve MS tarafından yapılandırılmış uygulamalar sözleşmeler. (Bu durumda SC, orijinal işlemleri yok sayacak şekilde değiştirilmelidir ve Çifte işlemeyi önlemek için yalnızca MS tarafından işlenenleri kabul edin.) Hedef sözleşme SC ile kullanım için MS, FSS ve/veya TEF ile birlikte kullanılabilir.3.6 Atlama Taşları: Mevcut Chainlink Yetenekler 3.6.1 Zincir Dışı Raporlama (OCR) Zincir Dışı Raporlama (OCR) [60], Chainlink'de oracle rapor toplama ve bağlı bir SC sözleşmesine aktarım için kullanılan bir mekanizmadır. Yakın zamanda Chainlink fiyatına dağıtıldı besleme ağları, tam DONs'ye giden yolda ilk adımı temsil eder. OCR özünde kısmen senkronize olarak çalışmak üzere tasarlanmış bir BFT protokolüdür. ağ. Keyfi olarak f < n/3 varlığında canlılık ve doğruluk sağlar. Bizans güvenilir yayınının özelliklerini garanti eden hatalı düğümler, ancak değil eksiksiz bir BFT fikir birliği protokolü. Düğümler mesaj günlüklerini tutmaz tüm görüşlerinde aynı olan bir defteri temsil etme anlamında tutarlı, ve protokolün lideri güvenliği ihlal etmeden kaçamak ifadelerde bulunabilir. OCR şu anda belirli bir mesaj türü için tasarlanmıştır: medyalaştırılmış toplama Katılımcı düğümler tarafından bildirilen (en az 2f +1) değerler. konusunda önemli bir güvence sağlar. SC için çıkardığı, onaylanmış raporlar olarak adlandırılan raporlara: Onaylanmış bir rapordaki medyan değer rapor iki dürüst düğüm tarafından bildirilen değerlere eşit veya bu değerler arasında yer alıyor. Bu mülk OCR için temel güvenlik koşulu. Liderin medyan üzerinde bir miktar etkisi olabilir. Onaylanmış bir rapordaki değer, ancak yalnızca bu doğruluk koşuluna tabidir. OCR yapılabilir değerleri farklı şekillerde bir araya getiren mesaj türlerini kapsayacak şekilde genişletilebilir. Chainlink ağının bugünkü canlılık ve doğruluk hedefleri, OCR'nin tam gelişmiş bir konsensüs protokolü olmasına rağmen, OCR'nin geleneksel BFT protokollerinde bulunmayan bazı ek işlevsellik biçimleri sağlamasını gerektirir; en önemlisi: 1. Zincir dışı rapor yayını ya hep ya hiç: OCR, onaylanmış bir raporun olmasını sağlar tüm dürüst düğümlerin kullanımına hızlı bir şekilde sunulur veya hiçbirinin kullanımına sunulmaz. Bu bir adalet Dürüst düğümlerin katılma fırsatına sahip olmasını sağlamaya yardımcı olan özellik onaylanmış rapor iletiminde. 2. Güvenilir aktarım: OCR, hatalı veya kötü niyetli aktarımların varlığında bile garanti sağlar tüm OCR raporlarının ve mesajlarının belirli bir süre içerisinde SC'ye iletilmesi, önceden tanımlanmış zaman aralığı. Bu bir yaşam mülküdür. 3. Sözleşmeye dayalı güven minimizasyonu: SC, potansiyel olarak hatalı OCR tarafından oluşturulan raporları filtreler; örneğin, rapor edilen değerleri diğer raporlardan önemli ölçüde sapıyorsa yakın zamanda alınanlar. Bu, ekstra protokol doğruluğu uygulamasının bir şeklidir. Bu özelliklerin üçü de DONs'de doğal bir rol oynayacaktır. Zincir dışı ya hep ya hiç (DON) yayını, kriptoekonomik güvenceler için önemli bir yapı taşıdır güvenilir iletim etrafında, bu da önemli bir adaptör özelliğidir. Güven SC'deki minimizasyon, Bölüm 7.3'te tartışıldığı gibi bir tür korkuluktur. OCR ayrıca Chainlink'nin oracle ağlarındaki BFT protokollerinin operasyonel dağıtımı ve iyileştirilmesi için bir temel sağlar ve dolayısıyla yukarıda belirtildiği gibi tam sürüme giden bir yol sağlar. DONs işlevselliği.3.6.2 DECO ve Town Crier DECO [234] ve Town Crier [233] şu anda kullanılmakta olan bir çift ilgili teknolojidir Chainlink ağlarında geliştirildi. Günümüzde çoğu web sunucusu, kullanıcıların bir protokol kullanarak güvenli bir kanal üzerinden bağlanmasına izin veriyor Aktarım Katmanı Güvenliği (TLS) [94] olarak adlandırılır. (HTTPS, HTTP'nin bir çeşidini belirtir: TLS ile etkinleştirilmiştir, yani "https" ön ekine sahip URL'ler güvenlik için TLS kullanımını belirtir.) Çoğu TLS özellikli sunucunun dikkate değer bir sınırlaması vardır: Dijital olarak imzalanmazlar veri. Sonuç olarak, bir kullanıcı veya Prover, bir sunucudan aldığı verileri sunamaz. sağlayacak şekilde oracle veya smart contract gibi bir üçüncü tarafa veya Doğrulayıcıya Verilerin orijinalliği. Bir sunucu verileri dijital olarak imzalasa bile gizlilik sorunu devam eder. Bir Prover, hassas verileri bir yetkiliye sunmadan önce çıkarmak veya değiştirmek isteyebilir. Doğrulayıcı. Ancak dijital imzalar, değiştirilmiş verileri geçersiz kılmak için özel olarak tasarlanmıştır. Böylece bir Prover'ın gizliliği koruyan değişiklikler yapmasını engellerler verilere. (Daha fazla tartışma için Bölüm 7.1'e bakın.) DECO ve Town Crier, Prover'ın bir web'den veri almasına olanak sağlayacak şekilde tasarlanmıştır sunucusuna aktarın ve bunu bütünlük ve gizlilik sağlayacak şekilde Doğrulayıcıya sunun. İki sistem, sunulan verilerin sağlanması anlamında bütünlüğü korur. Doğrulayıcıdan Doğrulayıcıya giden mesaj orijinal olarak hedef sunucudan gelir. Destekliyorlar Prover'ın verileri düzeltmesine veya değiştirmesine izin verme anlamında gizlilik (hala bütünlüğün korunması). Her iki sistemin de önemli özelliği herhangi bir değişiklik gerektirmemesidir. web sunucusunu hedefleyin. Mevcut herhangi bir TLS özellikli sunucuyla çalışabilirler. Aslında sunucuya karşı şeffaftırlar: Sunucunun bakış açısından, Prover sıradan bir bağlantı kurmak. İki sistemin de benzer hedefleri var ancak şimdi kısaca açıklayacağımız gibi güven modelleri ve uygulamaları farklı. DECO, bütünlüğünü sağlamak için kriptografik protokollerden temel düzeyde yararlanır ve gizlilik özellikleri. DECO'yu kullanarak hedef sunucuyla bir oturum oluştururken Prover, aynı zamanda sunucuyla etkileşimli bir protokole girer. Doğrulayıcı. Bu protokol, Doğrulayıcının Doğrulayıcıya aldığını kanıtlamasını sağlar. Geçerli oturumu sırasında sunucudan belirli bir D verisi parçası. Kanıtlayıcı şunları yapabilir: alternatif olarak Doğrulayıcıya D'nin bazı özelliklerine ilişkin sıfır bilgi kanıtını sunun ve dolayısıyla D'yi doğrudan açığa çıkarmaz. Tipik bir DECO kullanımında, bir kullanıcı veya tek bir düğüm, D verilerini özel bir ağdan dışarı aktarabilir. DON içindeki tüm düğümlere bir web sunucusuyla oturum açın. Sonuç olarak, DON'nın tamamı D'nin gerçekliğini (veya sıfır bilgi kanıtı yoluyla D'den türetilen bir gerçeği) kanıtlar. Makalenin ilerleyen kısımlarında verilen örnek uygulamalara ek olarak bu yetenek, Bir veri kaynağına yüksek bütünlüklü erişimi DON ile güçlendirmek için kullanılır. Tek bir düğüm olsa bile örneğin özel bir anlaşma nedeniyle bir veri kaynağına doğrudan erişimi vardır. bir veri sağlayıcısı—DON'nin tamamının doğruluğunu onaylaması mümkün olmaya devam ediyoro düğüm tarafından yayılan raporlar. Town Crier, Intel gibi güvenilir bir yürütme ortamının (TEE) kullanımına güveniyor SGX. Kısaca TEE, uygulamaları tek bir ortamda yürüten bir tür kara kutu işlevi görür. kurcalamaya dayanıklı ve gizli bir yol. Prensip olarak, üzerinde bulunulan ana bilgisayarın sahibi bile TEE çalışıyorsa, TEE korumalı bir uygulamayı (algılanamayacak şekilde) değiştiremez veya gizli verileri içerebilecek uygulamanın durumunu görüntüleyin. Town Crier, DECO'nun tüm işlevlerini ve daha fazlasını elde edebilir. DECO, Kanıtlayıcıyı tek bir Doğrulayıcı ile etkileşime girecek şekilde kısıtlar. Buna karşılık Town Crier şunları sağlar: Hedef sunucudan alınan D verileri üzerinde kamuya açık olarak doğrulanabilir bir kanıt oluşturacak bir Kanıtlayıcı, yani herkesin, hatta smart contract bile olsa doğrudan doğrulayabileceğinin kanıtı. Town Crier yapabilir ayrıca sırları (ör. kullanıcı kimlik bilgileri) güvenli bir şekilde alıp kullanın. Town Crier'ın ana sınırlaması TEE'lere bağımlı olmasıdır. Üretim TEE'leri Son zamanlarda, teknolojinin emekleme aşamasında olmasına ve şüphesiz olgunlaşacak olmasına rağmen, bir takım ciddi güvenlik açıklarına sahip olduğu gösterilmiştir. Ek B.2.1 ve B.2.2'ye bakınız. TEE'ler hakkında daha fazla tartışma. DECO ve Town Crier'ın birkaç örnek uygulaması için Bölüm 4.3, 4.5'e bakın. ve 9.4.3 ve Ek C.1. 3.6.3 Mevcut Zincir İçi Chainlink Hizmetler Chainlink oracle ağları çok sayıda ana hizmet sağlar blockchains ve günümüzün diğer merkezi olmayan sistemleri. Açıklandığı gibi daha fazla gelişme Bu teknik incelemede mevcut hizmetlere ek yetenekler kazandırılacak ve ulaşmak. Üç örnek: Veri beslemeleri: Bugün, smart contracts'ye güvenen Chainlink kullanıcıların çoğunluğu veri akışlarının kullanımı. Bunlar, önemli veri parçalarının mevcut değerine ilişkin raporlardır. Yetkili zincir dışı kaynaklara. Örneğin, fiyat feed'leri fiyatları bildiren feed'lerdir Varlıkların (kripto para birimleri, emtialar, forex, endeksler, hisse senetleri vb.) alışverişleri veya veri toplama hizmetleri. Bu tür yayınlar bugün zaten milyarların güvence altına alınmasına yardımcı oluyor Aave [147] gibi DeFi sistemlerinde kullanımları yoluyla zincir üstü değerde dolar değerinde Sentetik [208]. Chainlink veri feed'lerinin diğer örnekleri arasında hava durumu verileri yer alır: diğerlerinin yanı sıra parametrik mahsul sigortası [75] ve seçim verileri [93]. DONs ve bu belgede açıklanan diğer teknolojilerin dağıtımı, Chainlink ağlarında veri akışlarının sağlanmasını aşağıdakiler de dahil olmak üzere birçok açıdan geliştirecektir: • Ölçeklendirme: OCR ve ardından DON'ler, Chainlink hizmetlerinin ölçeklendirilmesine olanak sağlamayı amaçlamaktadır destekledikleri pek çok blockchain arasında çarpıcı bir şekilde. Örneğin, bekliyoruz DONs, düğümler tarafından sağlanan veri akışlarının sayısının artırılmasına yardımcı olacaktır. Chainlink 100'lerden 1000'lere ve ötesine. Bu tür bir ölçeklendirme Chainlink'ye yardımcı olacaktır. ekosistem, smart contracts ile ilgili verileri kapsamlı bir şekilde sağlama ve hem mevcut hem de gelecekteki ihtiyaçları karşılama ve öngörme hedefine ulaşıyor.• Gelişmiş güvenlik: DONs, ara raporları depolayarak kayıtları saklar Performanslarının ve doğruluğunun yüksek kalitede izlenmesi ve ölçülmesi için düğüm davranışlarının değerlendirilmesi, itibar sistemlerinin güçlü ampirik temellendirilmesine olanak sağlar Chainlink düğüm için. FSS ve TEF, fiyat feed'lerinin dahil edilmesini sağlayacak işlem verileriyle, önden çalıştırma gibi saldırıları önleyen esnek yöntemlerle. (Açık) staking güvenliğin mevcut kriptoekonomik korumasını güçlendirecek veri beslemeleri. • Feed çevikliği: blockchain-agnostik sistemler (aslında daha genel anlamda tüketici-agnostik sistemler) olarak DONs, çok sayıda veri feed'inin sağlanmasını kolaylaştırabilir güvenen sistemlerdir. Tek bir DON belirli bir feed'i eş zamanlı olarak bir diziye aktarabilir farklı blockchain'lerin sayısı, zincir başına oracle ağ ihtiyacını ortadan kaldırır ve mevcut feed'lerin yeni blockchain'lere ve ek akışlara hızla dağıtılmasına olanak tanır şu anda hizmet verilen blockchains genelinde yayınlar. • Gizlilik: DON'de genelleştirilmiş hesaplama gerçekleştirme yeteneği, hassas veriler üzerindeki hesaplamaların zincir dışında yapılmasını sağlayarak zincir üzerinde işlem yapılmasını önler maruz kalma. Ek olarak DECO veya Town Crier kullanarak aşağıdaki sonuçlara ulaşmak mümkündür: olmayan verilere dayalı rapor oluşturulmasına olanak tanıyan daha da güçlü gizlilik DON düğümlere bile maruz kalıyor. Örnekler için Bölüm 4.3 ve Bölüm 4.5'e bakınız. Doğrulanabilir Rastgele Fonksiyonlar (VRF'ler): Çeşitli DApp türleri, kendi adil işleyişinin doğrulanmasını sağlamak için doğrulanabilir şekilde doğru bir rastgelelik kaynağı gerektirir. Değiştirilemez Tokenlar (NFTs) bir örnektir. Aavegotchi [23] ve Axie Infinity [35]'deki NFT özelliklerinin nadirliği, dağılım gibi Chainlink VRF tarafından belirlenir NFT'lerin Ether Kartlarındaki bilet bazlı çizimler aracılığıyla [102]; geniş çeşitlilik sonuçları rastgele olan oyun DApp'leri; ve fonları tahsis eden PoolTogether [89] gibi kayıpsız tasarruf oyunları gibi geleneksel olmayan finansal araçlar rastgele kazananlar. Diğer blockchain ve blockchain olmayan uygulamalar da güvenli olmasını gerektirir Merkezi olmayan sistem komitelerinin seçimi ve piyangoların yürütülmesi. hashes bloğu öngörülemeyen bir rastgelelik kaynağı olarak hizmet edebilse de, rakip madenciler (ve bir dereceye kadar işlemler). Chainlink VRF [78] çok daha güvenli bir alternatif sunar. bir oracle, özel anahtarı zincir dışında tutulan ve genel anahtarı pk yayınlanan ilişkili bir özel/genel anahtar çiftine (sk, pk) sahiptir. Rastgele bir değer çıktısı almak için sk'yi, bağlı bir sözleşmeyle sağlanan öngörülemeyen bir tohum x'e uygular (örneğin, bir blok hash) ve DApp'e özgü parametreler) bir F fonksiyonu kullanarak, y = Fsk(x) ile birlikte elde edilir doğruluğunun kanıtı. (Chainlink adresinde mevcut olan VRF için [180] adresine bakın.) VRF doğrulanabilirliği, pk bilgisi ile kanıtın ve dolayısıyla y'nin doğruluğunun kontrol edilebilmesidir. Sonuç olarak y değeri tahmin edilemez. x'i tahmin edemeyen veya sk'yi öğrenemeyen ve hizmetin manipüle etmesi mümkün olmayan bir düşman.Chainlink VRF, zincir dışı özel anahtarların saklanmasını içeren bir uygulama ailesinden yalnızca biri olarak görülebilir. Daha genel olarak, DONs güvenli teklifler sunabilir, uygulamalar ve/veya kullanıcılar için ayrı anahtarların merkezi olmayan şekilde depolanması ve birleştirilmesi Bu yetenek genelleştirilmiş hesaplamayla sağlanır. Sonuç olarak bir dizi uygulama ortaya çıktı: Bu belgede Kanıt için anahtar yönetimi de dahil olmak üzere bazı örnekler veriyoruz. Rezervler (bkz. Bölüm 4.1) ve kullanıcıların merkezi olmayan kimlik bilgileri (ve diğer dijital varlıklar) (bkz. Bölüm 4.3). Bekçiler: Chainlink Bekçiler [87] geliştiricilerin merkezi olmayan uygulamalar için kod yazmasına olanak tanır genellikle smart contracts'ye bağlı olanların yürütülmesini tetiklemek için zincir dışı işlerin yürütülmesi. Keepers'ın ortaya çıkmasından önce, geliştiricilerin bu tür zincir dışı işlemleri yürütmesi yaygındı. mantığın kendisi merkezi başarısızlık noktaları yaratarak (aynı zamanda önemli ölçüde mükerrer geliştirme çabaları) yaratır. Bunun yerine koruyucular kullanımı kolay bir çerçeve sağlar. Bu operasyonların merkezi olmayan dış kaynak kullanımı, daha kısa geliştirme döngüleri ve canlılık ve diğer güvenlik özelliklerinin güçlü güvencesi. Bekçiler her türlü desteği verebilir Kredilerin fiyata bağlı tasfiyesi de dahil olmak üzere çok çeşitli tetikleyici hedeflerin veya finansal işlemlerin yürütülmesi, airdropların veya ödemelerin zamana bağlı olarak başlatılması verim toplama ve benzeri sistemlerde. DON çerçevesinde, başlatıcılar çeşitli açılardan Koruyucuların bir genellemesi olarak görülebilir. Başlatıcılar bağdaştırıcılardan yararlanabilir ve böylece Zincir içi ve zincir dışı sistemlere yönelik modülerleştirilmiş arayüz kütüphanesi; güvenli, gelişmiş işlevselliklerin geliştirilmesi. Başlatıcılar hesaplamayı başlatır DONs'nin tam çok yönlülüğünü sunan yürütülebilir dosyalar, Bu belgede zincir içi ve zincir dışı uygulamalar için sunduğumuz merkezi olmayan hizmetler yelpazesi. 3.6.4 Düğüm İtibarı / Performans Geçmişi Mevcut Chainlink ekosistemi, performans geçmişlerini yerel olarak belgelemektedir. Zincire katkıda bulunan düğümler. Bu özellik, bireysel performans verilerini alan, filtreleyen ve görselleştiren itibar odaklı bir kaynak koleksiyonunun ortaya çıkmasına neden olmuştur. düğüm operatörleri ve veri beslemeleri. Kullanıcılar bilgi sahibi olmak için bu kaynaklara başvurabilir düğüm seçiminde karar vermek ve mevcut ağların çalışmasını izlemek. Benzer yetenekler kullanıcıların DONs seçeneğini seçmesine yardımcı olacaktır. Örneğin, günümüzün market.link gibi izinsiz pazaryerleri node'a izin veriyor operatörler oracle hizmetlerini listeleyecek ve zincir dışı kimliklerini Chainlink içindeki bir düğümün profilini kendisine bağlayan Keybase [4] gibi hizmetler sahibinin mevcut alan adları ve sosyal medya hesapları. Ek olarak performans market.link ve itibar.link adreslerinde bulunanlar gibi analiz araçları, kullanıcılar, bireysel düğümlerin geçmiş performanslarına ilişkin istatistikleri görüntüleyebilirler. ortalama yanıt gecikmesi, raporlarındaki değerlerin fikir birliği değerlerinden sapması zincire aktarılır, elde edilen gelir, yerine getirilen işler ve daha fazlası. Bu analiz araçları aynı zamanda kullanıcıların çeşitli oracle ağlarının diğer kullanıcılar tarafından benimsenmesini izlemesine olanak tanır;bu tür ağların güvenliğini sağlayan düğümlerin örtülü olarak onaylanması. Sonuç düz bir "ağ"dır belirli düğümleri kullanarak yüksek değerli merkezi olmayan uygulamaların oluşturulduğu güven” diğer kullanıcıların gözlemleyebileceği ve bunları hesaba katabileceği düğümlere olan güvenlerinin bir sinyali kendi düğüm seçimi kararları. DONs ile (ve başlangıçta OCR ile) işlem süreçlerinde bir değişiklik geliyor ve daha genel olarak zincir dışı sözleşme faaliyetleri. Düğümü kaydetmek için merkezi olmayan bir model performans DON içinde mümkün olmaya devam ediyor. Aslında yüksek performans ve DONs'lik veri kapasitesi, kayıtların ayrıntılı bir şekilde oluşturulmasını mümkün kılar ve aynı zamanda bu kayıtlar üzerinde merkezi olmayan hesaplama gerçekleştirerek itibar hizmetleri tarafından kullanılabilecek ve kontrol noktalarına yerleştirilebilecek güvenilir özetler elde edilmesini sağlar. ANA ZİNCİR. Bir DON'nin, düğümlerin büyük bir kısmı bozulmuşsa, kurucu düğümlerin davranışını yanlış beyan etmesi prensipte mümkün olsa da, kolektif DON'in zincir içi veri sağlamadaki performansı MAINCHAIN'de görülebilir dolayısıyla yanlış beyan edilemez. Ek olarak, mekanizmaları keşfetmeyi planlıyoruz. DON'da düğüm davranışlarının doğru dahili raporlamasını teşvik edin. Örneğin, katkıda bulunan verileri en hızlı şekilde döndüren yüksek performanslı düğümlerin alt kümesini raporlayarak Zincir üzerinde iletilen bir rapora yönelik bir DON, düğümlerin yanlış itirazda bulunmaları için bir teşvik oluşturur raporlar: Düğümlerin bu alt kümeye hatalı şekilde dahil edilmesi, düğümlerin hatalı şekilde hariç tutulması anlamına gelir bunun dahil edilmesi gerekiyordu ve bu nedenle onları geçersiz bir şekilde cezalandırıyordu. DON tarafından tekrarlanan raporlama hataları, dürüst düğümlerin gruptan ayrılması için bir teşvik de yaratacaktır. DON. Doğru performans geçmişlerinin merkezi olmayan bir şekilde derlenmesi ve bunun sonucunda ortaya çıkan sonuçlar kullanıcıların yüksek performanslı düğümleri tanımlama ve düğüm operatörlerinin oluşturma yeteneği itibarlar Chainlink ekosisteminin önemli ayırt edici özellikleridir. Biz Bölüm 9'da titiz ve kapsamlı bir çalışmanın anahtar parçası olarak bunlar hakkında nasıl akıl yürütebileceğimizi göstereceğiz. DONs tarafından sağlanan ekonomik güvenliğin kapsamlı görünümü.

Merkezi Olmayan Tarafından Etkinleştirilen Merkezi Olmayan Hizmetler

Oracle Ağları DONs'nin çok yönlülüğünü ve bir dizi yeni hizmeti nasıl etkinleştirdiklerini göstermek için, bu bölümde DON tabanlı uygulamaların beş örneğini sunuyoruz ve Bunları gerçekleştiren hibrit sözleşmeler: (1) Zincirler arası hizmetin bir biçimi olan Rezerv Kanıtı; (2) Kurumsal/eski sistemlerle arayüz oluşturmak, yani ara katman yazılımı tabanlı bir sistem oluşturmak blockchain uygulamalarının minimum maliyetle geliştirilmesini kolaylaştıran soyutlama katmanı blockchain-özel kod veya uzmanlık; (3) Merkezi olmayan kimlik, kullanıcıların kendi kimlik belgelerini ve kimlik bilgilerini edinebilir ve yönetebilir; (4) Öncelikli kanallar, kritik altyapı işlemlerinin zamanında dahil edilmesini sağlayan bir hizmet (ör. oracle) raporlar) blockchain ile ilgili; ve (5) Gizliliği koruyan DeFi, yani mali Katılımcı tarafların hassas verilerini gizleyen smart contracts. Burada biz

Hibrit bir sözleşmenin ANA ZİNCİR bölümünü belirtmek ve DON'yi tanımlamak için SC'yi kullanın bileşeni ayrı ayrı veya yürütülebilir bir yürütme açısından. 4.1 Rezerv Kanıtı Birçok uygulama için, durumu blockchain'ler arasında veya arasında aktarmak faydalıdır. bir Bu tür hizmetlerin popüler uygulaması kripto para birimi paketlemedir. Böyle sarılmış paralar WBTC [15] Merkezi Olmayan Finans'ta popüler bir varlık haline geldiğinden (DeFi). onlar “sarılmış” destek varlığının kaynağına bırakılmasını içerir blockchain MAINCHAIN(1) ve farklı bir hedef blockchain MAINCHAIN(2) üzerinde karşılık gelen bir token oluşturmak. Örneğin, WBTC, Ethereum blockchain üzerinde karşılık gelen bir ERC20 token'dir. Bitcoin blockchain üzerinden BTC'ye. MAINCHAIN(2) üzerindeki sözleşmelerin MAINCHAIN(1) üzerinde doğrudan görünürlüğü olmadığından, ambalajlı ambalajların depozitoları hakkında rapor vermek için açıkça veya dolaylı olarak oracle'ye güvenmelidirler smart contract içindeki varlık, bazen Rezerv Kanıtı olarak adlandırılan şeyi üretir. içinde WBTC [15], örneğin saklama kurumu BitGo, BTC'yi tutar ve WBTC'yi ihraç eder. Chainlink Rezerv Kanıtları sağlayan ağ [76]. DON'nin kendisi bir Rezerv Kanıtı sağlayabilir. Ancak DON ile bu mümkündür daha ileri gitmek için. Bir DON gizli dizileri yönetebilir ve uygun bağdaştırıcıların kullanımı yoluyla istenilen herhangi bir blockchain üzerinde işlem yapılabilir. Sonuç olarak, DON'nin harekete geçmesi mümkündür bir dizi saklayıcıdan biri olarak veya hatta tek, merkezi olmayan bir saklayıcı olarak sarılmış bir varlık. DONs böylece güvenliği artıracak bir platform görevi görebilir. Rezerv Kanıtlarını kullanan mevcut hizmetler. Örneğin, MAINCHAIN(1)'in Bitcoin ve MAINCHAIN(2)'nin Ethereum olduğunu varsayalım. MAINCHAIN(2)'de, bir sözleşme SC, sarılmış BTC'yi temsil eden token'leri yayınlar. DON bir BTC adresi adresini kontrol eder(1) DON. BTC'yi sarmak için bir U kullanıcısı X BTC'yi gönderir. adres(1) sen adrese(1) DON ANA ZİNCİR(2)-adres adresi(2) ile birlikte U. DON monitörler adres(1) DON bir adaptör aracılığıyla MAINCHAIN(1)'e. U'nun para yatırma işlemini gözlemlemesi üzerine, yeterince yüksek olasılık onayı ile, SC'ye bir adaptör aracılığıyla bir mesaj gönderir. ANA ZİNCİR(2). Bu mesaj SC'ye addr(2) için X tokens basması talimatını verir. U. U'nun X tokens'yi serbest bırakması için bunun tersi gerçekleşir. Ancak MAINCHAIN(1)'de adres(1) DON X BTC'yi addr(1)'e gönderir U (veya kullanıcı tarafından talep edilmesi halinde başka bir adrese). Bu protokoller elbette doğrudan değil borsalarla çalışacak şekilde uyarlanabilir. kullanıcılarla. 4.2 Kurumsal / Eski Sistemlerle Arayüz Oluşturma DON'ler, Kanıt örneğinde olduğu gibi, blockchain'ler arasında köprü görevi görebilir Rezervlerin bir diğer amacı da rezervlerin arasında çift yönlü köprü görevi görmesidir. blockchains ve eski sistemler [176] veya merkez bankası gibi blockchain benzeri sistemler dijital para birimleri [30]. İşletmeler mevcut sistemlerini birbirine bağlama konusunda bir takım zorluklarla karşı karşıyadır ve aşağıdakileri içeren merkezi olmayan sistemlere yönelik süreçler:• Blockchain çevikliği: Blockchain sistemleri hızla değişiyor. Bir işletme, blockchains'nin hızla yeni ortaya çıkışı veya popülaritesinin artmasıyla karşı karşıya kalabilir. Karşı taraflar işlem yapmak istiyor ancak işletmenin bu konuda herhangi bir yetkisi yok. Mevcut altyapısına destek. Genel olarak, blockchains'nin dinamizmi bireysel işletmelerin ekosistemin tamamına ayak uydurması zordur. • Blockchain'e özel geliştirme kaynakları: Pek çok kuruluş için, en son teknolojiye sahip blockchain uzmanlığını işe almak veya kuluçkaya yatırmak zordur, özellikle de çeviklik mücadelesi. • Özel anahtar yönetimi: blockchains veya kripto para birimleri için özel anahtarları yönetmek, geleneksel siber güvenlikten farklı operasyonel uzmanlık gerektirir uygulamalar ve birçok işletme için mevcut değildir. • Gizlilik: Şirketler hassas ve özel bilgilerini ifşa etme konusunda temkinlidir zincirdeki veriler. Bu zorlukların ilk üçünü çözmek için geliştiriciler basitçe DON kullanabilirler. kurumsal sistemlerin okumasını veya yazmasını sağlayan güvenli bir ara yazılım katmanı olarak blockchains. DON aşağıdaki gibi ayrıntılı teknik hususları ortadan kaldırabilir: Hem geliştiriciler hem de kullanıcılar için gaz dinamikleri, zincirin yeniden düzenlenmesi vb. Tarafından kurumsal sistemlere kolaylaştırılmış bir blockchain arayüzü sunan DON böylece blockchain-bilinçli kurumsal uygulamaların geliştirilmesini önemli ölçüde basitleştirerek, işletmelerin blockchain-özel geliştirme kaynaklarını edinme veya kuluçkalama yükünü ortadan kaldırır. DONs'nin bu şekilde kullanılması, kurumsal geliştiricilere olanak sağlaması açısından özellikle çekicidir. büyük ölçüde blockchain agnostik olan akıllı sözleşme uygulamaları oluşturun. Sonuç olarak, DON aracının ara katman yazılımı olarak görev yapacağı blockchain kümesi ne kadar büyükse, kurumsal kullanıcıların kolayca erişebileceği blockchain kümesi daha büyük. Geliştiriciler uygulamaları mevcut blockchain'lerden minimum değişiklikle yenilerine taşıyabilir dahili olarak geliştirilen uygulamalara. Ek gizlilik sorununu çözmek için geliştiriciler, Bu belgede tanıttığımız araçlar ve DON uygulamaları desteklemek üzere dağıtılmasını bekliyoruz. Bunlar arasında DECO ve Town Crier Bölüm 3.6.2'nin yanı sıra gizliliğin korunması da yer almaktadır. Bölüm 7.1.2'de tartışılan API değişiklikleri ve bu bölümün geri kalanında ele alınan bir dizi uygulamaya özel yaklaşım. Bu DON sistemler şunları sağlayabilir: kurumsal sistem durumu hakkında yüksek düzeyde bütünlüklü, zincir üzerinde açıklamalar Zincirdeki hassas kurumsal kaynak verileri. 4.3 Merkezi Olmayan Kimlik Merkezi olmayan kimlik, kullanıcıların şunları yapabilmesi gerektiği kavramı için kullanılan genel bir terimdir. Bunu yapmak için üçüncü taraflara güvenmek yerine kendi kimlik bilgilerini alıp yönetin yani. Merkezi olmayan kimlik bilgileri, sahibinin niteliklerine veya iddialarına ilişkin tasdiklerdir.bunlara genellikle iddialar denir. Kimlik bilgileri, genellikle adı verilen kuruluşlar tarafından dijital olarak imzalanır. Talepleri kullanıcılarla yetkili bir şekilde ilişkilendirebilen ihraççılar. Önerilen planların çoğunda, talepler, evrensel bir tanımlayıcı olan Merkezi Olmayan Tanımlayıcı (DID) ile ilişkilidir. belirli bir kullanıcı. Kimlik bilgileri, kullanıcının özel anahtarının bulunduğu ortak anahtara bağlıdır. Böylece kullanıcı özel anahtarını kullanarak bir hak talebine sahip olduğunu kanıtlayabilir. Merkezi olmayan kimlik olarak vizyoner, mevcut ve önerilen planlar, örneğin, [14, 92, 129, 216], üç ciddi sınırlamaya sahiptir: • Eski uyumluluk eksikliği: Mevcut merkezi olmayan kimlik sistemleri, DID kimlik bilgilerini üretmek için verenler adı verilen yetkililer topluluğu. Çünkü mevcut web hizmetleri genellikle verileri dijital olarak imzalamaz; verenlerin başlatılması gerekir özel amaçlı sistemler olarak Çünkü bunu yapmak için hiçbir teşvik yok. merkezi olmayan kimlik ekosistemi, tavuk-yumurta sorunuyla sonuçlanır. diğerinde Başka bir deyişle, bir ihraççı ekosisteminin nasıl önyükleneceği belli değil. • Kullanılamayan anahtar yönetimi: Merkezi olmayan kimlik sistemleri, kullanıcıların şunları yapmasını gerektirir: özel anahtarları yönetmek, kripto para birimiyle ilgili deneyimlerin gösterdiği bir şey uygulanamaz bir yük olmak. Yaklaşık 4.000.000 Bitcoin olduğu tahmin edilmektedir. [194] anahtar yönetimi hataları nedeniyle sonsuza kadar kaybedildi ve birçok kullanıcı, [193] borsalarına sahip kripto varlıkları, böylece merkezi olmayan yapıya zarar veriyor. • Gizliliği koruyan Sybil direncinin olmaması: Oylama, token'lerin token satışları sırasında adil tahsisi vb. gibi uygulamaların temel güvenlik gereksinimi şudur: kullanıcılar birden fazla kimlik iddiasında bulunamaz. Mevcut merkezi olmayan kimlik önerileri, bunu başarmak için kullanıcıların gerçek dünyadaki kimliklerini açıklamalarını gerektirmektedir. Sybil direnci, dolayısıyla önemli gizlilik güvencelerini baltalıyor. Bu sorunları, düğümlerden oluşan bir komitenin birleşimini kullanarak çözmek mümkündür. DON içinde dağıtılmış hesaplamanın gerçekleştirilmesi ve DECO gibi araçların kullanılması veya Town Crier, CanDID [160] adlı bir sistemde gösterildiği gibi. DECO veya Town Crier, tasarım gereği mevcut web hizmetlerini hiçbir değişiklik yapmadan dönüştürebilir gizliliği koruyan kimlik bilgilerini veren kuruluşlara dönüşür. DON'nin ilgili dışa aktarımını sağlarlar Bu amaçla verileri bir kimlik bilgilerine dönüştürürken, gizli tutulması gereken hassas verileri gizler. kimlik bilgisinde görünür. Ek olarak, kullanıcılar için anahtar kurtarmayı kolaylaştırmak, böylece anahtar yönetimini ele almak Bir sorun varsa, DON kullanıcıların özel anahtarları gizli olarak paylaşılan biçimde saklamasına izin verebilir. Kullanıcılar şunları yapabilir: anahtarlarını DON içindeki düğümlere kanıtlayarak (benzer şekilde Town Crier veya kullanarak) kurtarın DECO—önceden belirlenmiş bir dizi web sağlayıcısıyla (ör. Twitter, Google, Facebook). Town Crier veya DECO kullanmanın faydası OAUTH, kullanıcı gizliliğidir. Bu iki araç, kullanıcının DON'ye ifşa etmesini önlemesine olanak tanır gerçek dünya kimliklerinin çoğu zaman türetilebildiği bir web sağlayıcı tanımlayıcısı. Son olarak, [160]'da gösterildiği gibi Sybil direncini sağlamak için DON'nın şunu yapması mümkündür: kullanıcılar için benzersiz gerçek dünya tanımlayıcılarının gizliliğini koruyan bir dönüşümünü gerçekleştirin (örneğin, Sosyal Güvenlik Numaraları (SSN'ler)) kullanıcı kaydı üzerine zincir üstü tanımlayıcılara aktarılır.Sistem böylece hassas veriler olmadan mükerrer kayıtları tespit edebilir. SSN'ler ayrı ayrı DON düğümlerine gösteriliyor.7 Bir DON, harici merkezi olmayan kimlik adına bu hizmetlerden herhangi birini sağlayabilir izinsiz veya izinli blockchains üzerindeki sistemler, örneğin Hyperledger örnekleri Indy [129]. Örnek uygulama: KYC: Merkezi olmayan kimlik, bir araç olarak umut vaat ediyor kullanıcı deneyimini iyileştirirken blockchains üzerindeki finansal uygulamalara yönelik gereksinimleri kolaylaştırın gizlilik. Çözüme yardımcı olabileceği iki zorluk, kara para aklamanın önlenmesi / müşterini tanı (AML / KYC) düzenlemeleri kapsamındaki akreditasyon ve uyumluluk yükümlülükleridir. Birçok ülkedeki AML düzenlemeleri, finansal kuruluşların (ve diğer işletmelerin) birlikte çalıştıkları kişi ve işletmelerin kimliklerini oluşturmasını ve doğrulamasını gerektirir. işlemleri gerçekleştirirler. KYC, bir finansal kurumun bileşeninin bir bileşenini oluşturur diğer şeylerin yanı sıra genellikle kullanıcı davranışlarının izlenmesini ve fon akışlarının izlenmesini de içeren daha geniş bir AML politikası. KYC genellikle kimlik bilgilerinin bir biçimde kullanıcıya sunulmasını içerir (ör. Bir kimlik belgesini kullanıcının yüzünün önünde tutarak çevrimiçi bir web formuna giriş bir video oturumunda vb.) Merkezi olmayan kimlik bilgilerinin güvenli bir şekilde oluşturulması ve sunulması prensipte çeşitli açılardan faydalı bir alternatif olabilir: (1) KYC süreci kullanıcılar ve finansal kurumlar için daha verimlidir, çünkü Yeterlilik belgesi alındığında herhangi bir finans kurumuna sorunsuz bir şekilde sunulabilir; (2) Uzlaşma yoluyla kimlik hırsızlığı fırsatlarını azaltarak dolandırıcılığı azaltmak video doğrulaması sırasında kişisel olarak tanımlanabilir bilgilerin (PII) ve sahtekarlığın kullanımı; ve (3) Kullanıcıların kontrolü elinde tutması nedeniyle finansal kurumlarda PII risklerinin azaltılması kendi verilerinden. Finansal kuruluşların AML uyum başarısızlıkları nedeniyle ödediği milyarlarca dolarlık cezalar ve birçok finans kuruluşunun KYC'ye yılda milyonlarca dolar harcadığı göz önüne alındığında, iyileştirmeler finansal kuruluşlar için önemli miktarda tasarruf sağlayabilir. ve buna bağlı olarak tüketiciler için [196]. Geleneksel finans sektörü yavaş olsa da yeni uyumluluk araçlarını benimsemek için DeFi sistemler bunu giderek daha fazla benimsiyor [43]. Örnek uygulama: Teminatsız krediler: Çoğu DeFi uygulaması Günümüzdeki destek kredileri yalnızca tam teminatlı kredilerden kaynaklanmaktadır. Bunlar verilen krediler Kredilerin değerini aşan değerde kripto para birimi varlıklarını yatıran borçlulara. Son zamanlarda DeFi topluluğunun genel olarak yetersiz teminatlı krediler olarak adlandırdığı kredilere ilgi arttı. Bunlar, aksine, ilgili teminatın verildiği kredilerdir. kredinin anapara değerinden daha düşük bir değere sahiptir. Teminatsız krediler genellikle geleneksel finansal kurumlar tarafından verilen kredilere benzemektedir. Güvenmek yerine Kredinin geri ödenmesinin garantisi olarak yatırılan teminat üzerine, bunun yerine borç vermeyi temel alıyorlar Borçluların kredi geçmişlerine ilişkin kararlar. 7Bu dönüşüm, dağıtılmış sözde rastgele işleve (PRF) dayanır.Yetersiz teminatlandırılmış krediler, DeFi borç verme piyasasının yeni ortaya çıkan ancak büyüyen bir bölümünü oluşturur. Geleneksel finansal kurumların kullandığı mekanizmalara benzerler. yasal sözleşmeler gibi kurumlar [91]. Büyümeleri için temel bir gereksinim geleneksel kredi verme kararlarında önemli bir faktör olan kullanıcı kredi itibarına ilişkin verileri güçlü bir bütünlük sağlayacak şekilde DeFi sistemlerine sağlama yeteneği olacaktır; doğru verinin güvencesi. DON etkinleştirilmiş merkezi olmayan bir kimlik sistemi, borçluların korurken, kredi itibarlarını kanıtlayan yüksek güvence kimlik bilgileri oluşturmak hassas bilgilerin gizliliği. Özellikle, borçlular bunları oluşturabilir kimlik bilgileri yetkili çevrimiçi kaynaklardan alınan kayıtlara dayalıdır ve yalnızca DON tarafından onaylanan veriler, potansiyel olarak hassas diğer verileri açığa çıkarmadan. için Örneğin, bir borçlu, kredi puanının şu şekilde olduğunu gösteren bir kimlik bilgisi oluşturabilir: kredi büroları kümesi belirli bir eşiği (örneğin 750) aşıyor, ancak bunu ifşa etmiyor Kesin puan veya kayıtlarındaki diğer veriler. Ayrıca istenirse bu tür kimlik bilgileri anonim olarak oluşturulabilir, yani kullanıcının adı hassas veri olarak değerlendirilebilir ve kendisi oracle düğümlerine veya merkezi olmayan kimlik bilgilerine açık değildir. Kimlik bilgisi uygulamaya bağlı olarak zincir üzerinde veya zincir dışında kullanılabilir. Özetle, bir borçlu, kredi verenlere kredileri hakkında temel bilgileri sağlayabilir. güçlü bir bütünlüğe sahip ve gereksiz, hassas bilgilerin açığa çıkması riski olmayan geçmişler veri. Borç alan kişi ayrıca gizliliği koruyan diğer çeşitli kimlik bilgilerini de sağlayabilir. Borç verme kararlarının alınmasında yardımcı olur. Örneğin, kimlik bilgileri borçlunun kimliğini doğrulayabilir. Bir sonraki örneğimizde gösterdiğimiz gibi (zincir dışı) varlıklara sahip olmak. Örnek başvuru: Akreditasyon: Pek çok yargı bölgesi, kayıtsız menkul kıymetlerin satılabileceği yatırımcı sınıfını sınırlandırmaktadır. Örneğin ABD'de SEC Düzenleme D, bu tür yatırım fırsatları için akredite olmak için bir bireyin net serveti 1 milyon dolar olmalı, belirli asgari gelir şartlarını karşılamalı veya belirli mesleki niteliklere sahip olmalıdır [209, 210]. Mevcut akreditasyon süreçler hantal ve verimsizdir; çoğu zaman bir onay mektubu gerektirir. bir muhasebeci veya benzeri bir kanıt. Merkezi olmayan bir kimlik sistemi, kullanıcıların kimlik bilgilerini oluşturmasına olanak tanıyacaktır. Akreditasyona uygunluğu kanıtlayan mevcut çevrimiçi finansal hizmet hesapları Daha verimli ve gizliliği koruyan bir KYC sürecini kolaylaştıran düzenlemeler.

Üstelik DECO ve Town Crier'ın gizliliği koruyan özellikleri bunlara izin verecektir Kullanıcının mali durumuna ilişkin ayrıntıları doğrudan ifşa etmeden, güçlü bir bütünlük güvencesiyle oluşturulacak kimlik bilgileri. Örneğin, bir kullanıcı bir kimlik bilgisi oluşturabilir herhangi bir ek açıklama yapmadan net değerinin en az 1 milyon dolar olduğunu kanıtlamak mali durumu hakkında bilgi aldı. 4.4 Öncelikli Kanallar Öncelikli kanallar, DON kullanılarak oluşturulması kolay, kullanışlı yeni bir hizmettir. Onların

amaç, MAINCHAIN'de seçilmiş, yüksek öncelikli işlemleri zamanında teslim etmektir ağ tıkanıklığı dönemlerinde. Öncelikli kanallar bir tür Blok alanı üzerinde vadeli işlem sözleşmesi ve dolayısıyla bir kripto emtia olarak, bu terimin bir parçası olarak türetilmiş bir terim Chicago Projesi'nin [61, 136]. Öncelik kanalları, finansal işlemler gibi sıradan kullanıcı düzeyindeki faaliyetler için değil, özellikle madencilerin oracles gibi altyapı hizmetlerini, sözleşmeler için yönetim işlevlerini vb. etkinleştirmelerini amaçlamaktadır. Aslında burada tasarlandığı gibi bir öncelik Ağdaki madencilik gücünün %100'ünden daha azı tarafından uygulanan kanal yalnızca Teslimat sürelerinde gevşek sınırlar sağlayarak, yüksek hıza bağımlı kullanımları önler önden koşmak gibi hedefler. Şekil 10: Öncelikli kanal, bir madenci M'nin veya daha genel olarak bir madencinin garantisidir. M madencileri kümesi—bir U kullanıcısına, τ işleminin D blokları içinde çıkarılacağını bildirir hafıza havuzuna dahil edilmesi. Bir sözleşme SC'si, aşağıdakileri uygulamak için DON izlemeyi kullanabilir Kanalın hizmet şartları. Öncelikli kanal, bir madenci veya bir grup madenci arasında yapılan bir anlaşma şeklini alır. (veya madencilik havuzları) Kanalı sağlayan M ve erişim için ücret ödeyen bir kullanıcı U. M, U'nun hafıza havuzuna bir τ işlemi gönderdiğinde (herhangi bir gas fiyatıyla,ancak önceden kararlaştırılan bir gaz limiti), M onu sonraki D blokları içindeki zincire yerleştirecektir.8 Fikir şematik olarak Şekil 10'da gösterilmektedir. Öncelikli kanal sözleşmesi açıklaması: Öncelikli bir kanal şu şekilde gerçekleştirilebilir: hibrit smart contract kabaca aşağıdaki gibidir. SC'nin MAINCHAIN'deki mantığı göstermesine izin veriyoruz ve exec tarafından DON üzerinde. SC, ABD'den \(d from M and an advance payment \)p depozito/hisse kabul ediyor DON yürütülebilir exec, bellek havuzunu izleyerek bir işlemin yerleştirilmesini tetikler U tarafından. U, M'nin kazdığı bir işlemi gönderirse SC'ye bir başarı mesajı gönderir. Servis arızası durumunda zamanında bir yol ve arıza mesajı. SC, bir başarı mesajı verildiğinde M'ye $p ödemesini gönderir ve kalan tüm parayı gönderir, Bir arıza mesajı alırsa $d dahil olmak üzere U'ya. Başarılı bir sonlandırma sonrasında, M'ye $d depozitosunu serbest bırakır. Madenci M elbette birden fazla kişiye aynı anda öncelikli kanallar sağlayabilir kullanıcılar önceden kararlaştırılan sayıda mesaj için U ile öncelikli bir kanal açabilirler. 4.5 Gizliliğin Korunması DeFi / Karışıklar Bugün, DeFi uygulamaları [1] kullanıcılara çok az gizlilik sağlıyor veya hiç gizlilik sağlamıyor: Tüm işlemler zincirde görülebilir. Çeşitli sıfır bilgi temelli yaklaşımlar, örneğin, [149, 217], işlem gizliliği sağlayabilir ve TEF bunları destekleyecek kadar geneldir. Ama bu yaklaşımlar kapsamlı değildir ve örneğin tipik olarak bir işlemin dayandığı varlık. DONs'de nihai olarak desteklemeyi planladığımız geniş bilgi işlem araçları seti, Bu tür boşlukları kapatabilecek çeşitli farklı yollarla gizliliği etkinleştirin ve diğer sistemlerin gizlilik güvencelerinin tamamlanmasına yardımcı olun. Örneğin, Chainlink Laboratuvar araştırmacıları [135] tarafından önerilen, gizliliği koruyan bir DeFi aracı olan Mixicles, verileri gizleyebilir bir finansal aracı destekleyen varlık türü ve DON'ya çok doğal bir şekilde uyuyor çerçeve. Karışımlar, basit bir ikili sayıyı gerçekleştirmek için kullanımları açısından en kolay şekilde açıklanır. seçeneği. İkili opsiyon, iki kullanıcının olduğu bir finansal araçtır. Oyuncu olarak [135] ile tutarlılık için buraya bakın, iki olası etkinliğe bahis yapın Sonuçlar, örneğin bir varlığın önceden belirlenmiş bir zamanda hedef fiyatı aşıp aşmadığı. Aşağıdaki örnek bu fikri göstermektedir. Örnek 2. Alice ve Bob, bir varlığın değerine dayalı bir ikili opsiyonun taraflarıdır Carol's Bubble Token (CBT) olarak adlandırıldı. Alice, CBT'nin piyasa fiyatının şu şekilde olacağına dair iddiaya giriyor: T zamanında en az 250 USD = 21 Haziran 2025 öğlen; Bob bunun tersini iddia ediyor. Her oyuncu önceden belirlenen son tarihe kadar 100 ETH yatırır. Kazanma pozisyonuna sahip oyuncu 200 ETH alır (yani 100 ETH kazanır). 8D elbette M'nin yüksek olasılıkla uyum sağlayabilmesini sağlayacak kadar büyük olmalıdır. için Örneğin, eğer M ağdaki madencilik gücünün %20'sini kontrol ediyorsa, D = 100'ü seçebilir, böylece başarısızlık olasılığı ≈2 × 10−10, yani milyarda birden az.Mevcut bir Chainlink oracle ağı O verildiğinde, akıllı bir ağ uygulamak kolaydır Örnek 2'deki anlaşmayı gerçekleştiren SC ile sözleşme yapın. İki oyuncunun her biri para yatırır SC'de 100 ETH. T'den bir süre sonra, O'ya r'nin fiyatını isteyen bir q sorgusu gönderilir. T.O zamanında TCMB bu fiyata ilişkin r raporunu SC'ye gönderir. SC daha sonra Alice'e para gönderir r ≥250 ise ve Bob değilse. Ancak bu yaklaşım zincirdeki r'yi ortaya çıkarır ve bunu kolaylaştırır Bir gözlemcinin ikili opsiyonun altında yatan varlığı çıkarması. Mixicles terminolojisinde, sonuç hakkında kavramsal olarak düşünmek faydalıdır. yüklem olarak hesaplanan bir ikili değeri ileten bir Anahtar cinsinden SC'nin anahtar(r). Örneğimizde, r ≥250 ise anahtar(r) = 0; bu sonuç göz önüne alındığında Alice kazanır. Aksi takdirde geçiş(r) = 1 ve Bob kazanır. Bir DON, yürütülebilir bir dosyayı çalıştırarak temel bir Mixicle'ı hibrit bir sözleşme olarak gerçekleştirebilir switch(r)'yi hesaplayan ve zincirde SC'ye rapor eden exec. Bu yapıyı gösteriyoruz Şekil 11'de. Şekil 11: Örnek 2'deki temel Karışım diyagramı. oracle raporu r'yi ve dolayısıyla ikili opsiyonun temelini oluşturan varlığı gönderir. SC'yi yalnızca ikili değer anahtarını(r) Değiştirerek sözleşme yapın. Bunu başarmayı kolaylaştıran bir ConfSwitch adaptörünü Ek C.3'te belirtiyoruz. DON'deki gol. ConfSwitch'in arkasındaki temel fikir oldukça basittir. Rapor etmek yerine r değeri, ConfSwitch yalnızca ikili anahtar değeri anahtarını(r) bildirir. SC olabilir Yalnızca Switch(r)'e ve Switch(r)'in tek başına doğru ödeme yapması için tasarlanmıştır örneğimizde dayanak varlık olan TCMB hakkında hiçbir bilgi ortaya çıkarmaz. Ek olarak, pkaud altında şifrelenmiş defterdeki (q, r) üzerine şifreli bir metin yerleştirerek, genel anahtarı Bir denetçi olarak ConfSwitch bağdaştırıcısı gizliliği koruyan bir denetim izi oluşturur. Burada açıklamayı basitleştirmek için seçtiğimiz temel Mixicle yalnızca Örneğimizde ikili opsiyonun arkasındaki varlık ve bahis. Tam gelişmiş bir Mixicle [135] olabilir iki tür gizlilik sağlar. Gözlemcilerden şunları gizler: (1) Hangi olay oyuncular (yani q ve r) üzerine bahis oynarlar, aynı zamanda (2) Bahsi hangi oyuncunun kazandığına da bahis oynarlar. Mixicle'lar ANA ZİNCİR üzerinde yürütüldüğünden, iki oyuncunun da aktarma yapması gerekir DON'dan MAINCHAIN'e geçiş yapın (r) veya çalıştırılabilir bir exec oluşturulabilir.

ConfSwitch tarafından çıkışta tetiklenir ve anahtarı (r) göndermek için başka bir bağdaştırıcıyı çağırır. ANA ZİNCİR. Gizliliğin üçüncü, incelikli türü de dikkate alınmaya değerdir. ConfSwitch'in temel bir uygulamasında O, bağdaştırıcıyı DON üzerinde çalıştırıyor ve böylece varlık (örneğimizde TCMB) ve dolayısıyla ikili opsiyonun doğası. Tartışıldığı gibi Ancak Ek C.3'te ayrıca DECO veya Town Crier'ın kullanılması da mümkündür. Bu bilgiyi bile O'dan gizler. Bu durumda O daha fazla bilgi öğrenmez SC'nin halka açık bir gözlemcisinden daha fazla. Mixicles hakkında daha fazla ayrıntı için okuyucuları [135] adresine yönlendiriyoruz.

Fuar Sıralama Hizmetleri

DON'lerin ağ oluşturma, hesaplama ve depolama yeteneklerini güçlendiren sunmasını beklediğimiz önemli hizmetlerden biri Adil Sıralama Hizmetleri (FSS) olarak adlandırılıyor. FSS, basit bir şekilde DON çerçevesinde gerçekleştirilen bir uygulama olarak görülse de, dünya çapında yüksek talep göreceğine inandığımız bir hizmet olarak altını çiziyoruz. blockchains ve Chainlink ağının aktif olarak desteklemesini bekliyoruz. Günümüzün çoğu DeFi uygulaması, halka açık blockchain ağlarda yürütüldüğünde kullanıcılar tarafından kendi çıkarları doğrultusunda kullanılabilecek bilgileri ortaya çıkarmak; Mevcut piyasalarda yaygın olan içeriden bilgi sızıntıları ve manipülasyon fırsatları pazarlar [64, 155]. FSS bunun yerine adil bir DeFi ekosistemine giden yolu açıyor. FSS geliştiricilerin piyasa manipülasyonundan korunan DeFi sözleşmeler oluşturmalarına yardımcı olur bilgi sızıntısından kaynaklanmaktadır. Aşağıda vurguladığımız sorunlar göz önüne alındığında, FSS özellikle katman-2 hizmetleri için caziptir ve bu tür hizmetlerin çerçevesine uyar Bunu Bölüm 6'da tartışıyoruz. Zorluk: Mevcut izinsiz sistemlerde işlemler tamamen sıralıdır madencilerin takdirine bağlıdır. İzin verilen ağlarda validator düğümleri güç harcayabilir aynı güç. Bu, büyük ölçüde tanınmayan geçici bir merkezileşme biçimidir. aksi takdirde merkezi olmayan sistemler. Bir madenci kendi adına işlemleri (geçici olarak) sansürleyebilir. kendi çıkarını [171] veya kendi kazancını en üst düzeye çıkaracak şekilde yeniden sıralayın; bu, madenden çıkarılabilir değer (MEV) [90] olarak adlandırılan bir kavramdır. MEV terimi biraz yanıltıcıdır: yalnızca madencilerin yakalayabileceği değere: Bazı MEV'ler sıradan kullanıcılar tarafından yakalanabilir. Ancak madenciler sıradan kullanıcılardan daha fazla güce sahip olduğundan MEV, herhangi bir kuruluşun rekabete dayalı yeniden sıralama yoluyla elde edebileceği değer miktarı üzerinde bir üst sınır temsil eder. ve tamamlayıcı işlem ekleme. Madenciler işlemleri basit bir şekilde sipariş ettiğinde bile ücretlere (gas) dayalı olarak, manipülasyon olmaksızın, kullanıcılar gaz fiyatlarını kendileri değiştirebilirler işlemlerini daha az karmaşık işlemlere göre avantajlı hale getirmek. Daian ve diğerleri. [90] botların (madenciler değil) kullandığı yöntemleri belgeliyor ve ölçüyor gaz dinamiğinin günümüzde DeFi sistem kullanıcılarına zarar verecek şekilde avantajı ve nasıl MEV, blockchain'deki temel fikir birliği katmanının istikrarını bile tehdit ediyor. İşlem emri manipülasyonunun diğer örnekleri düzenli olarak ortaya çıkar, örneğin [50, 154].rollups gibi yeni işlem işleme yöntemleri çok umut verici bir yaklaşımdır yüksek verimli blockchains'nin ölçeklendirme sorunlarına. Ancak hitap etmiyorlar MEV'in sorunu. Bunun yerine, onu rollup oluşturan varlığa kaydırırlar. bu smart contract operatörü veya (zk-)rollup sağlayan bir kullanıcı olsun, varlık geçerlilik kanıtı, işlem sipariş etme ve ekleme yetkisine sahiptir. Başka bir deyişle, rollups MEV'yi REV ile değiştirin: Toplama Çıkarılabilir Değer. MEV, bellek havuzuna gönderilen yaklaşan işlemleri etkiler ancak henüz zincire bağlı değiller. Bu tür işlemlere ilişkin bilgiler genel olarak ağda mevcuttur. Madenciler, validator'ler ve sıradan ağ katılımcıları bu nedenle bu bilgiden yararlanın ve bağımlı işlemler yaratın. Ayrıca madenciler ve validator'ler gerçekleştirdikleri işlemlerin sırasını etkileyebilirler ve bunu kendi çıkarları doğrultusunda kullanırlar. Liderlerin fikir birliğine dayalı işlem sıralaması üzerinde aşırı etkisi sorunu protokoller literatürde 1990'lardan beri bilinmektedir [71, 190], ancak tatmin edici değildir çözümler şu ana kadar pratikte gerçekleştirildi [97]. Bunun temel nedeni, önerilen çözümlerin -en azından çok yakın zamana kadar- kamu kurumlarıyla kolayca entegre edilememesidir. blockchains, işlemlerin içeriğinin o tarihe kadar gizli kalmasına güvendikleri için sıralamaları belirlendi. Adil Sıralama Hizmetlerine (FSS) genel bakış: DONs, işlem sıralamasını merkezi olmayan hale getirmek ve bunu güvenilir bir kurum tarafından belirlenen bir politikaya göre uygulamak için araçlar sağlayacak İdeal olarak adil olan ve sözleşme yapmak isteyen aktörlere avantaj sağlamayan sözleşme yaratıcısı. işlem sırasını manipüle etmek. Bu araçlar toplu olarak FSS'yi oluşturur. FSS üç bileşen içerir. Birincisi işlemlerin izlenmesidir. FSS'de, O'daki oracle düğümleri hem MAINCHAIN'in bellek havuzunu izler hem de (istenirse) izin verir İşlemlerin özel bir kanal aracılığıyla zincir dışı olarak sunulması. İkincisi işlemlerin sıralanmasıdır. Bağlı bir sözleşme için O sipariş işlemlerindeki düğümler söz konusu sözleşme için tanımlanan bir politikaya göre. Üçüncüsü işlemlerin yayınlanmasıdır. İşlemler sıralandıktan sonra O'daki düğümler işlemleri ortaklaşa gönderir. ana zincir. FSS'nin potansiyel faydaları şunları içerir: • Sipariş adaleti: FSS, geliştiricilerin işlemlerin doğru yapılmasını sağlamasına yardımcı olacak araçlar içerir Belirli bir sözleşmeye girdinin haksızlık yaratmayacak şekilde sıralanması iyi kaynaklara sahip ve/veya teknik açıdan bilgili kullanıcılara avantaj sağlar. Sipariş politikaları Bu amaç için belirlenebilir. • Bilgi sızıntılarının azaltılması veya ortadan kaldırılması: FSS, ağ katılımcılarının yaklaşan işlemlerle ilgili bilgilerden yararlanamamasını sağlayarak, sızıntıları azaltabilir veya ortadan kaldırabilir. mevcut bilgilere dayanan önden çalıştırma gibi saldırıları ortadan kaldırın İşlemler gerçekleştirilmeden önce ağ. Bu tür istismarların önlenmesi sızıntı, orijinal beklemede olanlara bağlı çekişmeli işlemlerin yapılmasını sağlar işlemler, orijinal işlemler gerçekleştirilmeden önce deftere giremez.• Daha düşük işlem maliyeti: Oyuncuların gönderim hızı ihtiyacını ortadan kaldırarak işlemlerini smart contract'ye aktarırsanız FSS, işlem işleme maliyetini büyük ölçüde azaltabilir. • Öncelik sıralaması: FSS, kritik işlemlere otomatik olarak özel öncelik verebilir Sipariş vermek. Örneğin, oracle'ya yönelik ön saldırıları önlemek için raporlar, örneğin [79], FSS bir işlem akışına oracle raporu ekleyebilir geriye dönük olarak. DONs'deki FSS'nin genel hedefi, DeFi içerik oluşturucuların adil bir şekilde gerçekleştirmelerini sağlamaktır. Finansal sistemler, yani belirli kullanıcılara (veya madencilere) avantaj sağlamayan sistemler hız, içeriden edinilen bilgi veya teknik performans becerisi temelinde diğerlerine göre manipülasyon. Net, genel bir adalet kavramı elde edilmesi zor olsa da, mükemmel bir adalet makul bir anlam elde edilemez, FSS geliştiricilere güçlü bir hizmet sunmayı amaçlamaktadır. DeFi için tasarım hedeflerine ulaşmalarına yardımcı olacak politikaları uygulayabilmelerini sağlayan bir dizi araç. FSS'nin asıl amacının adil bir sıralama hizmeti olarak hareket etmek olduğunu belirtmek isteriz. DONs'nin hedeflediği ANA ZİNCİR, FSS'nin istediği adillik ile aynı garantiler aynı zamanda aralarında yürütülen (merkezi olmayan) protokoller için de uygun olabilir. DON partiler. Böylece, FSS daha geniş anlamda bir alt küme tarafından sağlanan bir hizmet olarak görülebilir. DON düğümün yalnızca MAINCHAIN kullanıcıları tarafından gönderilen işlemleri değil adil bir şekilde sıralanmasını da sağlıyor ancak aynı zamanda diğer DON düğümleri arasında paylaşılan işlemler (ör. mesajlar). Bu bölümde, Öncelikle MAINCHAIN işlemlerini sıralama hedefine odaklanacağız. Bölüm organizasyonu: Bölüm 5.1'de, FSS tasarımını motive eden iki üst düzey uygulamayı açıklıyoruz: oracle raporlarının önden çalıştırılmasının önlenmesi ve Kullanıcı işlemlerinin önden yürütülmesi. Daha sonra FSS'nin tasarımı hakkında daha fazla ayrıntı sağlıyoruz Bölüm 5.2'de. Bölüm 5.3, adil sipariş garantileri ve araçlarının örneklerini açıklamaktadır onlara ulaşmak için. Son olarak Bölüm 5.4 ve Bölüm 5.5'te ağ düzeyindeki tehditler tartışılmaktadır. sırasıyla ağ taşması ve Sybil için bu tür politikalar ve bunları ele alma araçları saldırılar. 5.1 Önden Çalışan Sorun FSS'nin amaçlarını ve tasarımını açıklamak için, önden koşmanın iki genel biçimini tanımlıyoruz. saldırılar ve mevcut çözümlerin sınırlamaları. Önde koşan bir sınıf örneğidir işlem siparişi saldırılarının sayısı: Geriye koşma ve sandviçleme (önden çalıştırma artı geri çalıştırma) [237] gibi ele almadığımız bir dizi ilgili saldırı vardır burada, ancak FSS aynı zamanda bu sorunun çözülmesine de yardımcı oluyor. 5.1.1 Oracle Önde Çalışan blockchain uygulamalara zincir dışı veri sağlama şeklindeki geleneksel rollerinde, oracles önden gelen saldırılar için doğal bir hedef haline gelir.Çeşitli fiyat feed'lerini sağlamak için oracle kullanma şeklindeki ortak tasarım modelini göz önünde bulundurun zincir içi bir borsaya: periyodik olarak (örneğin her saat başı), oracle aşağıdakiler için fiyat verilerini toplar: farklı varlıkları alıp bunları bir takas sözleşmesine gönderir. Bu fiyat-veri işlemleri bariz arbitraj fırsatları sunuyor: Örneğin, en yeni oracle raporu listeliyorsa bazı varlıklar için çok daha yüksek bir fiyat, bir rakip oracle raporunu önden yayınlayabilir varlıkları satın alın ve oracle'nin raporu işlendikten sonra bunları hemen yeniden satabilirsiniz. Hız tümsekleri ve geriye dönük fiyatlandırma: oracle önden çalıştırma sorununa doğal bir çözüm, oracle raporlara diğer işlemlere göre özel öncelik vermektir. için örneğin, madencileri işleme teşvik etmek için oracle raporları yüksek ücretlerle gönderilebilir ilk önce onlar. Ancak arbitraj fırsatı yüksekse bu önden koşmayı engellemez, madencilerin kendilerinin arbitraj yapmasını da engelleyemez. Bu nedenle bazı borsalar, kullanıcı işlemlerini işlemden önce birkaç blok için sıraya koymak gibi daha ağır "hız artışları" uygulamaya başvurdu. veya yeni bir oracle raporu geldiğinde fiyatları geriye dönük olarak ayarlamak. Bu çözümlerin dezavantajları, değişim uygulamasına karmaşıklık katmalarıdır. depolama gereksinimlerini ve dolayısıyla işlem maliyetlerini artırır ve varlık takasları yalnızca önemli bir süre sonra onaylandığından kullanıcı deneyimini bozar. Bindirme: FSS'ye geçmeden önce, oldukça basit ve basit bir yöntem olan sırtlamayı tartışıyoruz. oracle önden çalıştırma sorununa zarif bir çözüm. Adres için geçerli değildir Ancak diğer senaryolarda önde gidiyor. Kısacası, zincir üstü sözleşmeye periyodik olarak rapor göndermek yerine oracles Kullanıcıların satın alırken veya satarken işlemlerine eklediği imzalı raporları yayınlayın zincir üstü varlıklar. Borsa daha sonra raporun geçerli ve yeni olup olmadığını kontrol eder (örneğin, oracle raporun geçerli olduğu bir dizi bloğu imzalayabilir) ve alıntılar yapar ilgili fiyat beslemesi ondan alınır. Bu basit yaklaşımın yukarıdaki "hız tümseğine" göre birçok avantajı vardır. yaklaşım: (1) Takas sözleşmesinin fiyat beslemelerinin durumunu korumasına gerek yoktur; daha düşük işlem maliyetlerine yol açar; (2) oracle raporları zincir halinde ihtiyaç esasına göre yayınlandığından, oracle'ler daha sık güncellemeler (örneğin her dakika) oluşturabilir, böylece bir raporun önden yayınlanmasından kaynaklanan arbitraj fırsatlarının en aza indirilmesi9; (3) İşlemler yapılabilir her zaman yeni bir fiyat akışı içerdikleri için hemen doğrulanmaları gerekir. Ancak yaklaşım mükemmel değil. İlk olarak, bu bindirme çözümü Güncel oracle raporları alıp bunları kendi borsalarına ekleme sorumluluğu borsanın kullanıcılarına düşüyor. işlemler. İkincisi, sırtlama arbitraj fırsatlarını en aza indirirken, Zincir üstü sözleşmenin canlılığını etkilemeden bunları tamamen önleyin. Aslında eğer bir oracle raporu, n numaralı bloka kadar geçerlidir, ardından bloğa bir işlem gönderilir n + 1 yeni ve geçerli bir rapor gerektirir. Yayılmasındaki doğal gecikmeler nedeniyle oracles'den kullanıcılara rapor gönderiyorsa, n + 1 bloğu için geçerli olan yeni rapor 9Arbitraj, yalnızca varlık fiyatlarındaki sömürülebilir farkın dışsal fiyatları aşması durumunda değerlidir. Varlıkları satın almak ve satmak için gereken ücretler (örneğin madenciler ve borsa tarafından toplananlar).n + 1 bloğunun çıkarılmasından bir süre önce, örneğin n −k bloğunda duyurulacak, böylece Kısa ömürlü bir arbitraj fırsatının mevcut olduğu bir dizi k blok oluşturmak. Biz Şimdi FSS'nin bu sınırlamaları nasıl aştığını açıklayın. FSS ile oracle raporların önceliklendirilmesi: FSS, oracle ön çalıştırma sorununu ele alabilir Yukarıdaki bindirme çözümünü temel alarak, ancak ek çözümleri zorlayarak sorun Merkezi Olmayan Oracle Ağına gönderilen oracle raporlarıyla işlemleri artırma çalışması. Yüksek düzeyde, oracle düğümleri zincir içi bir borsaya yönelik işlemleri toplar, Gerçek zamanlı bir fiyat akışı üzerinde anlaşın ve toplanan işlemlerle birlikte fiyat akışını ana zincir sözleşmesine gönderin. Kavramsal olarak bu yaklaşımı şu şekilde düşünebiliriz: oracle'nin güncel bir işlem yapılmasını sağladığı "verilerle zenginleştirilmiş işlem toplu işlemi" fiyat akışı her zaman işlemlere eklenir. FSS çözümleri borsanın kullanıcılarına şeffaf bir şekilde uygulanabilir ve Bölüm 5.2'de daha ayrıntılı olarak açıkladığımız gibi, sözleşme mantığında minimum değişiklikler. Sağlama yeni oracle raporların her zaman kullanıcı işlemlerine göre önceliklendirilmesi yalnızca bir örnektir FSS'nin benimseyebileceği ve uygulayabileceği bir sipariş politikasının. FSS'nin düzeni sağlamaya yönelik politikaları adalet Bölüm 5.3'te daha genel olarak açıklanmaktadır. 5.1.2 Önden Çalışan Kullanıcı İşlemleri Şimdi yukarıdaki savunma yönteminin geçerli olduğu genel uygulamalarda önden çalıştırmaya dönüyoruz. çalışmıyor. Sorun aşağıdaki senaryo aracılığıyla genel olarak ele alınabilir: Bir saldırgan, P2P ağına gönderilen bazı tx1 kullanıcı işlemlerini görür ve kendi çekişmeli işlemi tx2'dir, böylece tx2, tx1'den önce işlenir (örneğin, ödeme yaparak) daha yüksek bir işlem ücreti). Örneğin, bu tür önden koşmalar arasında yaygındır. DeFi sistemlerdeki [90] arbitraj fırsatlarından yararlanan ve kullanıcılarını etkileyen botlar çeşitli merkezi olmayan uygulamalar [101]. İşlemler arasında adil bir düzenin sağlanması blockchain üzerinde işlenen bu sorunu giderir. Daha da önemlisi, tx1'in ayrıntılarını görmek bazen gerekli bile olmuyor ve onun varlığının bilinmesi, bir rakibin tx1'i kendi aracıyla önden çalıştırmasına izin verebilir. tx2'ye sahip olun ve tx1'i yaratan masum kullanıcıyı dolandırın. Örneğin, kullanıcı Belirli bir varlığın düzenli zamanlarda ticaretini yaptığı biliniyor. Bu tür saldırıların önlenmesi, meta veri sızıntısını da önleyen azaltıcı önlemler [62]. Bu soruna yönelik bazı çözümler mevcuttur, ancak gecikmelere ve kullanılabilirlik endişelerine neden olurlar. FSS ile ağ siparişinden kesinleşmiş siparişe: Önde koşma fırsatları mevcut sistemlerin düzeni sağlayacak mekanizmalara sahip olmaması nedeniyle ortaya çıkmaktadır. işlemler zincir halinde görünür, olayların sırasına ve bilgi akışına saygı gösterir ağ dışında. Bu, blockchain üzerindeki uygulamaların (örneğin ticaret platformları) uygulanmasındaki eksikliklerden kaynaklanan bir sorunu temsil eder. İdeal olarak, biri işlemlerin blockchain üzerinde yapıldıkları sırayla gerçekleştirildiğinden emin olun oluşturuldu ve blockchain'nin P2P ağına gönderildi. Ancak blockchain ağından beri

dağıtılırsa böyle bir sipariş yakalanamaz. FSS bu nedenle mekanizmaları devreye sokar yalnızca dağıtılan dağıtım nedeniyle ortaya çıkan adalet ihlallerine karşı koruma sağlamak blockchain ağının doğası. 5.2 FSS Ayrıntıları Şekil 12: İki farklı işlem yoluna sahip sipariş fuarı bellek havuzu: doğrudan ve bellek tabanlı. Şekil 12, FSS'nin genel şemasını göstermektedir. Adilliği sağlamak için, FSS sağlayan DON, MAINCHAIN'e girerken işlemlerin akışına müdahale etmelidir. İstemcilerde, MAINCHAIN'deki smart contracts'de veya her ikisinde de ayarlamalar yapılması gerekli olabilir. Yüksek düzeyde, işlemlerin FSS tarafından işlenmesi üçe ayrılabilir: aşağıda açıklanan aşamalar: (1) İşlem izleme; (2) İşlem sıralaması; ve (3) İşlem kaydı. İşlem sıralaması için kullanılan sıralama yöntemine bağlı olarak, bir sonraki bölümde açıklandığı gibi ek protokol adımlarına ihtiyaç vardır. 5.2.1 İşlem İşleme İşlem izleme: FSS'nin izlemesi için iki farklı yaklaşım öngörüyoruz belirli bir smart contract'ye yönelik, doğrudan ve bellek havuzu tabanlı kullanıcı işlemleri: • Doğrudan: Doğrudan yaklaşım kavramsal olarak en basittir ancak işlemlerin doğrudan Merkezi Olmayan Oracle'a gönderilmesini sağlamak için kullanıcı istemcileriAna zincirin düğümleri yerine ağ düğümleri. DON toplar belirli bir smart contract SC'ye yönlendirilen kullanıcı işlemleri ve bunları temel alarak sıralar bazı sipariş politikası hakkında. DON daha sonra sipariş edilen işlemleri smart contract ana zincirde. Bazı sipariş mekanizmaları aynı zamanda doğrudan yaklaşımı da gerektirir çünkü bir işlemi oluşturan kullanıcının kriptografik olarak işlem yapması gerekir. FSS'ye göndermeden önce onu koruyun. • Mempool tabanlı: FSS'nin eski istemcilerle entegrasyonunu kolaylaştırmak için DON ana zincirin bellek havuzunu izlemek ve veri toplamak için Mempool Hizmetlerini (MS) kullanabilir işlemler. Doğrudan iletimin birçok sözleşme için tercih edilen uygulama olması muhtemeldir, ve bunun birçok durumda oldukça pratik olması gerektiğine inanıyoruz. Desteklemek için mevcut DApp'lerin nasıl minimum düzeyde değiştirilebileceğini kısaca tartışıyoruz. İyi bir kullanıcı deneyimini korurken doğrudan iletim. Yaklaşımları tanımlıyoruz Ethereum ve MetaMask [6] kullanılıyor çünkü bunlar günümüzün en popüler seçimleri, ancak Bahsedilen tekniklerin diğer zincirlere ve cüzdanlara da yayılması gerekiyor. Yeni bir Ethereum İyileştirme Teklifi, “EIP-3085: Cüzdan ekleme Ethereum zincir RPC yöntemi” [100], özel Ethereum zincirlerini hedeflemeyi kolaylaştıracak (farklı bir ZİNCİR ID kullanarak) MetaMask ve diğer tarayıcı tabanlı cüzdanlardan tekrar oynatma saldırılarını önlemek için MAINCHAIN'inki) Bu teklifin uygulanmasının ardından bir DON kullanmak isteyen bir DApp doğrudan iletebilmek için ön uçlarına tek bir yöntem çağrısı eklerler Ethereum uyumlu bir API'yi açığa çıkaran herhangi bir DON işlemine. Bu arada, "EIP-712: Ethereum yazılan yapısal veriler hashing ve imzalama" [49] biraz sağlar bir DApp kullanıcısının kullanabileceği, daha kapsamlı ancak zaten yaygın olarak dağıtılmış bir alternatif DON işlemini belirten yapılandırılmış verileri imzalamak için MetaMask. DApp gönderebilir bu imzalı yapısal veri DON'ye. Son olarak hibrit yaklaşımların da mümkün olduğunu belirtiyoruz. Örneğin, miras istemciler işlemleri ana zincirin bellek havuzuna göndermeye devam edebilir ancak bu kritik bir öneme sahiptir işlemler (ör. oracle raporlar) doğrudan DON düğümlere gönderilir (özellikle Fiyat feed'i güncellemeleri ve düğüm kümesi gibi oracle raporlar sağlayan düğüm kümesi FSS'nin sağlanması örtüşebilir veya aynı olabilir). İşlem sıralaması: FSS'nin temel amacı, kullanıcı işlemlerinin önceden tanımlanmış bir politikaya göre sıralanmasını garanti etmektir. Bu politikanın niteliği uygulamanın ihtiyaçlarına ve sunduğu haksız işlem emirlerinin türüne bağlıdır. önlemeyi amaçlamaktadır. DON üzerindeki FSS, verileri işleme ve yerel durumu koruma yeteneğine sahip olduğundan, elde edilen bilgilere dayanarak keyfi bir sıralama politikası uygulayabilirler. oracles adresinde mevcuttur. Özel düzenleme politikaları ve bunların uygulanması daha sonra Bölüm 5.3'te tartışılmaktadır.İşlem ilanı: Doğrudan kullanıcılardan alınan veya bellek havuzundan toplanan kullanıcı işlemlerini toplayıp sipariş ettikten sonra DON bu işlemleri ana zincire gönderir. Bu nedenle, bir DON'nin ana zincirle olan etkileşimleri devam eder ana zincirin madencileri tarafından yönetilen (potansiyel olarak adil olmayan) işlem emrine tabidir. Merkezi olmayan işlem emrinin avantajlarından yararlanmak için hedef akıllı Dolayısıyla sözleşme SC'nin DON'ye "birinci sınıf" vatandaş muamelesi yapacak şekilde tasarlanması gerekir. Biz iki yaklaşımı ayırt edin: • DON-yalnızca sözleşmeler: En basit tasarım seçeneği, ana zincirin akıllı olmasını sağlamaktır SC sözleşmesi yalnızca DON tarafından gerçekleştirilen işlemleri kabul eder. Bu smart contract'nin işlemleri önerilen sırayla işlemesini sağlar DON, ancak fiilen smart contract'yi komite tabanlı bir sistemde çalışacak şekilde kısıtlıyor (yani, DON komitesi artık işlemlerin sıralanması ve dahil edilmesi). • İki sınıflı sözleşmeler: Tercih edilen, daha ayrıntılı bir tasarım, ana zinciri akıllı hale getirir sözleşme SC, hem DON hem de eski sözleşmeden kaynaklanan işlemleri kabul eder kullanıcılar10 ancak DON tarafından işlenmeyen işlemlere geleneksel "hız artışları" uygular. Örneğin, DON numaralı telefondan gelen işlemler işlenebilir eski işlemler smart contract tarafından "arabelleğe alınır". sabit bir zaman dilimi. Önden koşmayı önlemeye yönelik diğer standart mekanizmalar taahhüt-açıklama şemaları veya VDF'ler [53] gibi eski uygulamalara da uygulanabilir işlemler. Bu, DON sıralı işlemlerin şu tarihte işlenmesini sağlar: DON'ye istenmeyen sansür yetkisi vermeden karara varılan emir işlemler. FSS tarafından işlem emrinin uygulanması, işlemlerin "zincir dışı" olarak toplanmasını gerektirdiğinden, bu çözüm doğal olarak zincir içi işlem maliyetlerini azaltmayı amaçlayan diğer toplama teknikleriyle birleştirilir. Örneğin topladıktan sonra işlemleri sipariş etmek için DON bu işlemleri ana zincire bir e-posta olarak gönderebilir. tek bir "toplu işlem" (ör. rollup), böylece toplam işlem azalır ücret. İşlem emrinin uygulanması: İster yalnızca DON isterse çift sınıflı tasarımda olsun, smart contract SC ana zinciri ve DON, DON'nın işlem sırasının yerine getirileceğini garanti edecek şekilde birlikte tasarlanmalıdır. Burada da farklı düşünüyoruz tasarım seçenekleri: • Sıra numaraları: DON her işleme bir sıra numarası ekleyebilir ve bu işlemleri ana zincirin bellek havuzuna gönderebilir. ana 10DON'in işlem izlemesi bellek havuzuna dayanıyorsa, eski işlemlerin DON işlemlerinden ayırt edilebilmesi gerekir, böylece DON tarafından örneğin özel bir etiket aracılığıyla toplanmazlar. işleme gömülü olarak veya belirli bir gaz fiyatı belirterek, ör. DON işlemlerde gaz var Fiyatlar belli bir eşiğin altında.zincir smart contract SC, "sıra dışı" gelen işlemleri yok sayar. Biz bu ortamda ana zincir madencilerinin DON'yi göz ardı etmeye karar verebileceğini unutmayın. işlem siparişi vererek işlemlerin başarısız olmasına neden olur. SC'nin (pahalı) durumunu koruyarak doğru işlem sırasını uygulaması mümkündür. TCP'nin, eksik paketler giderilinceye kadar sıra dışı paketleri nasıl tamponladığına benzer şekilde alındı. • İşlem nonces: Birçok blockchains için ve özellikle Ethereum için, yukarıdaki sıra numaralandırma yaklaşımı yerleşik nonces işleminden yararlanabilir smart contract SC ana zincirinin işlemleri sırayla işlemesini zorunlu kılın. Burada, DON düğümleri, işlemleri DON düğümleri arasında paylaşılan bir anahtarla korunan tek bir ana zincir hesabı aracılığıyla ana zincire gönderir. Hesabın nonce işlemi, işlemlerin doğru sırayla çıkarılmasını ve işlenmesini sağlar. • İşlemleri birleştir: DON, birden fazla işlemi rollup içinde toplayabilir (veya rollup benzeri bir pakette). Ana zincirin smart contract olması gerekiyor bu tür toplu işlemleri gerçekleştirmek için tasarlanmıştır. • İşlemleri bir ana zincir proxy'si ile toplayın: Burada DON, benzer şekilde işlemleri ana zincir için tek bir "meta-işlem" halinde birleştirir, ancak bir işlemleri paketinden çıkarmak ve bunları sunucuya aktarmak için özel proxy smart contract hedef sözleşme SC. Bu teknik eski uyumluluk için yararlı olabilir. Meta işlemler rollup'ler gibi davranır ancak sıkıştırılmamış bir dosyadan oluşmaları bakımından farklılık gösterir. Ana zincire bir kez gönderilen işlemlerin listesi. Son tasarım, kullanıcı işlemlerini sorunsuz bir şekilde destekleme avantajına sahiptir. DON hedefine ulaşmadan önce bir ana zincir sözleşmesi aracılığıyla kendilerine vekalet ediliyor sözleşme SC. Örneğin, bir cüzdana işlem gönderen bir kullanıcıyı düşünün. sözleşme, bu da SC'ye dahili bir işlem gönderir. Sıra atama Kullanıcının cüzdan sözleşmesi geçerli olmadığı sürece böyle bir işleme numara verilmesi yanıltıcı olacaktır. sıra numarasını her dahili işlemde iletmek için özel olarak tasarlanmıştır. SC. Benzer şekilde, bu tür dahili işlemler doğrudan SC'ye gönderilen bir meta işlemde kolayca toplanamaz. Daha fazla tasarım hususunu tartışıyoruz aşağıda bu tür proxy işlemleri. 5.2.2 İşlem Atomikliği Şu ana kadar yaptığımız tartışma, üstü kapalı olarak işlemlerin tek bir işlemle etkileşime girdiğini varsayıyordu. zincir üzerinde smart contract (örneğin, bir kullanıcının borsaya satın alma isteği göndermesi). Yine de Ethereum gibi sistemlerde, tek bir işlem birden fazla dahili işlemden oluşabilir; örneğin, bir smart contract başka bir sözleşmedeki bir işlevi çağırır. Aşağıda biz "Çok sözleşmeli" işlemleri sıralamak için iki üst düzey stratejiyi tanımlarken, işlemin atomikliğinin (yani, tarafından öngörülen eylem sırasının) korunması İşlemin tamamı doğru sırayla gerçekleştirilir veya hiç yürütülmez).Güçlü atomite: En basit çözüm, yukarıda açıklandığı gibi FSS'yi doğrudan tüm "çok sözleşmeli" işlemlere uygulamaktır. Yani kullanıcılar işlemlerini gönderiyorlar ağa girer ve FSS bu işlemleri izler, sıralar ve ana zincir. Bu yaklaşım teknik olarak basittir ancak potansiyel bir sınırlaması vardır: işlem, her ikisinin de adil bir şekilde yararlanmak istediği iki sözleşme SC1 ve SC2 ile etkileşime giriyor Hizmetlerin sıralanması durumunda bu iki sözleşmenin sıralama politikasının tutarlı olması gerekir. Yani, her birinin etkileşime girdiği iki farklı tx1 ve tx2 işlemi verildiğinde Hem SC1 hem de SC2, SC1 politikasının tx1'i tx2'den önce sipariş etmesi söz konusu olmamalıdır. oysa SC2'nin politikası tam tersini öngörüyor. İlgili senaryoların büyük çoğunluğu için, farklı sözleşmeler tarafından benimsenen sıralama politikalarının tutarlı olacağını öngörüyoruz. Örneğin hem SC1 hem de SC2 İşlemlerin bellek havuzuna yaklaşık varış zamanına göre sıralanmasını isteyebilir, ve SC1 ayrıca belirli oracle raporların her zaman önce teslim edilmesini isteyebilir. Olarak son oracle rapor işlemleri SC2 ile etkileşime girmez, politikalar tutarlıdır. Zayıf atomiklik: Genel olarak FSS, bireysel düzeyde uygulanabilir. dahili işlemler. Bazı başlangıçlardan oluşan tx = { ˜txpre, ˜txSC, ˜txpost} biçimindeki işlemleri düşünün. işlem(ler) ˜txpre; bu, ˜txSC'den SC'ye dahili bir işlemle sonuçlanır; dahili işlem(ler)i yayınlar ˜txpost. SC'nin sıralama politikası nasıl yapılacağını belirleyebilir dahili işlem ˜txSC, gönderilen diğer işlemlere göre sıralanmalıdır SC'ye gidin, ancak 'txpre ve' txpost için sıralama sırasını açık bırakın. Ethereum gibi sistemlerdeki işlem işlemenin esasları göz önüne alındığında, belirli dahili işlemleri hedefleyen bir sıralama hizmeti geliştirmek kolay değildir. Özel olarak tasarlanmış bir sözleşme SC ile bu, aşağıdaki şekilde gerçekleştirilebilir: 1. tx işlemi ağa gönderilir ve madenciliği yapılır (herhangi bir sıralama olmadan) FSS tarafından gerçekleştirildi). İlk ˜txpre yürütülür ve ˜txSC'yi çağırır. 2. SC, txSC'yi çalıştırmaz ve geri döner. 3. FSS, SC'ye yapılan dahili işlemleri izler, sıralar ve geri gönderir SC'ye (yani, txSC işlemlerini doğrudan SC'ye göndererek). 4. SC, FSS'den alınan txSC işlemlerini işler ve txSC'den kaynaklanan dahili txpost işlemlerini düzenler. Bu yaklaşımla, işlemler tamamen atomik olarak (yani orijinal) yürütülmez. işlem tx birden fazla zincir içi işleme bölünür), ancak bunların sırası dahili işlemler korunur. Bu çözüm bir takım tasarım kısıtlamalarını gerektirir. Örneğin, 'txpre olamaz ˜txSC ve ˜txpost'un yürütüleceğini varsayalım. Ayrıca SC, şu şekilde tasarlanmalıdır: belirli bir kullanıcı adına txSC ve txpost işlemlerini yürütmekFSS tarafından gönderildi. Bu nedenlerden dolayı daha kaba taneli “Güçlü Atomiklik” çözümü Yukarıdakiler pratikte muhtemelen tercih edilir. Birden fazla işlemi içeren daha karmaşık bağımlılıklara saygı göstermek ve ilgili dahili işlemleri, FSS'nin işlem planlayıcısı şunları içerebilir: ilişkisel yönetimlerin işlem yöneticilerinde bulunanlara benzeyen ayrıntılı işlevler veritabanı yöneticileri. 5.3 Adil İşlem Sıralaması Burada, işlem sıralaması için iki adalet kavramını ve FSS tarafından gerçekleştirilebilecek ilgili uygulamaları tartışıyoruz: bir politikaya dayalı sipariş adaleti FSS tarafından uygulanan ve FSS'de ek şifreleme yöntemleri gerektiren güvenli nedensellik koruması. Düzen adaleti: Düzen adaleti, fikir birliği protokollerinde geçici adalet kavramıdır Bu ilk kez Kelkar ve ark. tarafından resmi olarak tanıtılmıştır. [144]. Kelkar ve ark. işlemlerin gerçekleştirildiği bir doğal politika biçimine ulaşmayı amaçlamaktadır. DON (veya P2P ağı, bellek havuzu tabanlı FSS durumunda). Merkezi olmayan bir sistemde ise farklı düğümler işlemlerin farklı bir sırayla geldiğini görebilir. Toplam bir düzen oluşturmak Tüm işlemlerde, temeldeki fikir birliği protokolü tarafından çözülen sorun tam da budur ANA ZİNCİR. Kelkar ve ark. [144] bu nedenle daha zayıf bir kavram ortaya koyuyor "blok sipariş adaleti" adı verilen Merkezi Olmayan Oracle Ağının yardımıyla elde edildi. DON öğesinin belirli bir zaman aralığında aldığı işlemleri bir grup halinde gruplandırır. “blok” ve bloğun tüm işlemlerini aynı anda ve aynı konuma ekler (yani yükseklik) ANA ZİNCİR'e. Bu nedenle birlikte sıralanırlar ve çalıştırılabilir olmaları gerekir paralel olarak, aralarında herhangi bir çatışma yaratmadan. Kabaca söylemek gerekirse, düzen adaleti, eğer düğümlerin büyük bir kısmı τ1 işlemini τ2'den önce görürse, o zaman şunu belirtir: τ1, τ2'den önce veya aynı blokta sıralanacaktır. Böyle kaba bir dayatma yaparak İşlem emrindeki ayrıntı düzeyi, önden çalıştırma ve diğer emir bağlantılı saldırı fırsatları büyük ölçüde azalır. Kelkar ve ark. Aequitas [144] adı verilen bir protokol ailesi önermektedir. senkronize, kısmen senkronize ve senkronize olmayan ağ ayarları dahil olmak üzere farklı dağıtım modelleri. Aequitas protokolleri, temel BFT konsensusuna göre önemli düzeyde iletişim yükü getirir ve bu nedenle pratik kullanım için ideal değildir. Ancak Aequitas'ın kullanılabilecek pratik çeşitlerinin ortaya çıkacağına inanıyoruz. FSS ve diğer uygulamalarda işlem sıralaması için. İlgili bazı planlar var daha az formalizme ve daha zayıf özelliklere sahip olanların zaten önerildiği, örneğin, [36, 151, 236], ancak daha iyi pratik performans. Bu programlar desteklenebilir FSS'de de var. Ayrıca “adil olma” teriminin blockchain belgesinin başka yerlerinde de yer aldığını belirtmekte fayda var. Farklı bir anlam taşıyan edebiyat, yani fırsat anlamında adalet.madenciler taahhüt ettikleri kaynaklarla [106, 181] veya validators cinsinden orantılıdır fırsat eşitliği [153]. Güvenli nedenselliğin korunması: Dağıtılmış platformlarda önden çalıştırmayı ve diğer sıralama ihlallerini önlemeye yönelik en yaygın olarak bilinen yaklaşım, kriptografiye dayanır. teknikler. Bunların ortak özelliği, işlem verilerinin kendisini gizleyip, Konsensüs katmanındaki düzen oluşturuldu ve işlem verileri ortaya çıkarıldı daha sonra işlenmek üzere. Bu, işlemler arasındaki nedensellik sırasını korur. blockchain tarafından yürütüldü. İlgili güvenlik kavramları ve şifreleme protokolleri blockchains'nin ortaya çıkışından oldukça önce geliştirildi [71, 190]. "Girdi nedenselliği" [190] ve "güvenli nedenselliğin korunması" [71, 97] güvenlik koşulları, resmi olarak bir işlemle ilgili hiçbir bilginin bilinmemesini gerektirir Bu işlemin küresel düzendeki konumu belirlenmeden önce. Bir saldırganın o zamana kadar kriptografik olarak herhangi bir bilgi çıkaramaması gerekir. güçlü anlam. Nedenselliği korumak için dört şifreleme tekniği ayırt edilebilir: • Taahhüt-açıklama protokolleri [29, 142, 145]: Bir işlemin duyurulması yerine Açıkçası, yalnızca işleme yönelik kriptografik bir taahhüt yayınlanıyor. Taahhüt edilen ancak gizli olan tüm işlemler sipariş edildikten sonra (blockchain başında) MAINCHAIN'in kendi sistemleri üzerinde, ancak burada FSS tarafından), gönderenin taahhüdü açması ve işlem verilerini önceden belirlenmiş bir zaman aralığı içinde açıklaması gerekir. Ağ daha sonra açılışın önceki taahhüdü karşıladığını doğrular. bu yöntemin kökenleri blockchains'nin ortaya çıkışından öncesine dayanmaktadır. Her ne kadar özellikle basit olsa da, yaklaşım önemli dezavantajlara sahiptir ve iki nedenden dolayı uygulanması kolay değildir. Birincisi, sipariş protokolü düzeyinde yalnızca taahhüt mevcut olduğundan, işlemin semantiği fikir birliği sırasında doğrulanamaz. Müşteriye ek bir gidiş-dönüş gereklidir. Ancak daha ciddi olanı, hiçbir açıklığın açılmama ihtimalini ağırlaştırıyor. Bu, hizmet reddi saldırısı anlamına gelebilir. Ayrıca, Açılışın tutarlı, dağıtılmış bir ortamda geçerli olup olmadığını belirlemek zordur. çünkü tüm katılımcılar açılışın gerçekleşip gerçekleşmediği konusunda hemfikir olmalıdır. zaman. • Gecikmeli kurtarma ile taahhüt-açıklama protokolleri [145]: taahhüt-açıklama yaklaşımı, bir müşterinin bir işlemi spekülatif olarak taahhüt etmesi ve bunu ancak sonraki işlemler onu karlı hale getirirse daha sonra açıklayabilmesidir. bir taahhüt-açıklama yaklaşımının son versiyonu buna karşı dayanıklılığı artırıyor bir nevi yanlış davranış. Özellikle TEX protokolü [145] bu sorunu giderir şifrelenmiş işlemlerin bir şifre çözme anahtarı içerdiği akıllı bir yaklaşım kullanmak doğrulanabilir bir gecikme fonksiyonunun (VDF) hesaplanmasıyla elde edilebilir [53, 221]. Eğer bir müşteri işleminin şifresini zamanında çözemezse sistemdeki diğer kişiler şifreyi çözer orta derecede zor bir kriptografik bulmacayı çözerek onun adına.• Eşik şifrelemesi [71, 190]: Bu yöntem, DON'nin gerçekleştirebileceğinden yararlanır eşik şifreleme işlemleri. FSS'nin genel bir şifrelemeyi sürdürdüğünü varsayalım anahtar pkO ve oracle'ler ilgili özel anahtarı kendi aralarında paylaşırlar. İstemciler daha sonra işlemleri pkO altında şifreler ve bunları FSS'ye gönderir. FSS siparişleri DON üzerindeki işlemleri yapar, ardından bunların şifresini çözer ve en sonunda bunları ANA ZİNCİR sabit sırayla. Şifreleme bu nedenle siparişin doğru olmasını sağlar işlem içeriğine bağlı değildir, ancak verilerin kendisi şu durumlarda mevcuttur: ihtiyaç vardı. Bu yöntem ilk olarak Reiter ve Birman [190] tarafından önerilmiş ve daha sonra Cachin ve diğerleri tarafından geliştirilmiştir. [71], izin verilen bir fikir birliğiyle entegre edildi protokol. Daha yeni çalışmalar eşik kriptografisinin kullanımını araştırdı. genel mesajlar [33, 97] ve paylaşılan verilerle genel hesaplamalar için fikir birliği düzeyinde mekanizma [41]. Taahhüt-açıklama protokolleriyle karşılaştırıldığında eşik şifreleme, basit hizmet reddi saldırılarını önler (ancak şifre çözmenin hesaplama maliyeti göz önüne alındığında dikkatli olunması gerekir). DON'nin otonom olarak, kendi hızında ve daha fazla müşteri eylemi bekleniyor. İşlemler şifresi çözüldükten hemen sonra doğrulanabilir. Üstelik istemciler tüm işlemleri tek bir şifreyle şifreliyor DON anahtarına basın ve iletişim düzeni diğer anahtarlarla aynı kalır işlemler. Eşik anahtarını güvenli bir şekilde ve değişen düğümlerle yönetme Ancak O ek zorluklara neden olabilir. • Taahhüt edilen gizli paylaşım [97]: İşlem verilerini şifrelemek yerine DON tarafından tutulan bir anahtar varsa, istemci bunu O'daki düğümler için de gizli olarak paylaşabilir. Hibrit, hesaplama açısından güvenli bir gizli paylaşım şeması kullanarak işlem İlk önce rastgele bir anahtara sahip simetrik bir şifre kullanılarak şifrelenir. Yalnızca karşılık gelen simetrik anahtar paylaşılır ve şifreli metin DON'ye gönderilir. İstemci, ayrı olarak şifrelenmiş bir mesaj kullanarak O'daki her düğüme bir anahtar paylaşımı göndermelidir. Geri kalan protokol adımları eşik ile aynıdır İşlem verilerinin şifresinin simetrik yöntemle çözülmesi dışında şifreleme algoritma, işlem başına anahtarı paylaşımlarından yeniden oluşturduktan sonra. Bu yöntem, açık anahtarlı bir şifreleme sisteminin kurulumunu veya yönetimini gerektirmez DON ile ilişkili. Ancak istemcilerin düğümlerin farkında olması gerekir. O ve her biriyle güvenli bir bağlamda iletişim kurun; Müşterilere ek yük. Kriptografik yöntemler bilgiye karşı tam koruma sağlasa da Gönderilen işlemlerden ağa sızdıkları için meta verileri gizlemezler. için örneğin, gönderenin IP adresi veya Ethereum adresi yine de kullanılabilir. Önden koşan ve diğer saldırıları gerçekleştirecek bir düşman. Gizliliği artıran çeşitli ağ katmanında, örneğin [52, 95, 107] veya işlem katmanında konuşlandırılan teknikler, örneğin, [13, 65], bu hedefe ulaşmak için gerekli olacaktır. Belirli bir parçanın etkisi Meta verinin (bir işlemin hangi sözleşmeye gönderildiği) (kısmen) gizlenebilmesibirçok sözleşmeyi aynı DON üzerinde çoğaltarak. Kriptografik gizleme İşlemlerin sayısı aynı zamanda işlemlerin yolsuzlukla önceliklendirilmesini de engellemez. DON düğümleri işlem gönderenlerle gizli anlaşma içinde. Kriptografik protokoller tarafından garanti edilen güvenli nedensellik, herhangi bir politika için düzen adaleti garantilerini tamamlar ve biz bu ikisinin bir kombinasyonunu keşfetmeyi amaçlıyoruz. Bunun mümkün olduğu durumlarda yöntemler. Eğer rakip önemli bir avantaj elde edemiyorsa Meta verileri gözlemleyerek, güvenli nedensellik koruma protokolleri yanında kullanılabilir. aynı zamanda naif bir sıralama yaklaşımı. Örneğin, oracle düğümleri işlemleri yazabilir bunları alır almaz L'ye, çoğaltmadan. İşlemler daha sonra L'deki görünümlerine göre sıralanır ve ardından şifresi çözülür. Ayrıca, adil düzenlemenin uygulanmasına yardımcı olacak bir yol olarak TEE'lerin kullanımını da değerlendirmeyi planlıyoruz; için örneğin, Tesseract [44] bir tür nedensel sıralamaya ulaşıyor olarak görülebilir, ancak bir tanesi TEE'nin işlemleri açık biçimde işleme yeteneği ile güçlendirilmiştir. gizliliklerini koruyorlar. 5.4 Ağ Katmanında Dikkat Edilmesi Gerekenler Şu ana kadar FSS'ye ilişkin açıklamamız temel olarak aşağıdakileri uygulama sorununa odaklandı: İşlemlerin nihai sırası, ağda gözlemlenen sıra ile eşleşir. ahiret, ağ katmanının kendisinde ortaya çıkabilecek adalet sorunlarını dikkate alıyoruz. Geleneksel elektronik pazarlardaki yüksek frekanslı tüccarlar önemli miktarda yatırım yapıyor üstün ağ hızı elde etmek için kaynaklar [64] ve kripto para birimi borsalarındaki tüccarlar da benzer davranışlar sergiliyor [90]. Ağ hızı her iki durumda da avantaj sağlar diğer tarafların işlemlerini gözlemlemek ve rakip işlemleri sunmak. Pratikte uygulanan ve Flash Boys [155] kitabında popüler hale getirilen çözümlerden biri şudur: ilk olarak IEX borsasında [128] ve daha sonra diğer borsalarda tanıtılan "hız artışı" [179] değişimleri (karışık sonuçlarla [19]). Bu mekanizma, pazardaki avantajları etkisiz hale getirmek amacıyla pazara erişimde bir gecikme (IEX'te 350 mikrosaniye) uygular. hız. Ampirik kanıtlar, ör. [128], belirli ticareti azaltmadaki etkinliğini destekliyor sıradan yatırımcılar için maliyetler. FSS, asimetrik bir sistemi uygulamak için basitçe kullanılabilir. hız artışı — gelen işlemleri geciktiren bir artış. Budish, Cramton ve Shim [64] hızdaki avantajlardan faydalanmanın sürekli zamanlı piyasalarda kaçınılmazdır ve yapısal bir çözüm için tartışılmaktadır. toplu açık artırmaya dayalı pazarlar biçimi. Ancak bu yaklaşım geniş çapta benimsenmedi mevcut ticaret platformlarında. Geleneksel ticaret sistemleri merkezileştirilmiştir ve genellikle işlemleri tek bir ağ bağlantısı. Merkezi olmayan bir sistemde ise aksine, şunları yapmak mümkündür: İşlem yayılımını birden fazla bakış açısından gözlemleyin. Sonuç olarak bir P2P ağında ağ taşması gibi davranışları gözlemlemek mümkündür. Niyet ediyoruz geliştiricilerin politikaları belirlemesine yardımcı olan FSS'ye yönelik ağ katmanı yaklaşımlarını keşfetmek bu tür istenmeyen ağ davranışlarının yasaklanması.5.5 Kuruluş Düzeyinde Adillik Politikaları Sipariş adaleti ve güvenli nedensellik, işlemler üzerinde bir sıralamanın uygulanmasını amaçlamaktadır. oluşturuldukları ve ağa ilk gönderildikleri zamana saygı duyar. Bu adalet kavramının bir sınırlaması, düşmanın saldırılarını engellememesidir. gözlemlenen bir stratejiye göre, sistemi birçok işlemle doldurarak avantaj elde ediyor token satışlarda [159] etkili işlem gözetleme gerçekleştirmenin bir yolu olarak vahşi doğada ve Teminatlandırılmış borç pozisyonlarının (CDP'ler) tasfiyesiyle sonuçlanan tıkanıklık yaratmak [48]. Başka bir deyişle, düzen adaleti, oyunculara değil, işlemlere ilişkin adaleti zorunlu kılar. CanDID sistemi [160]'de gösterildiği gibi, DECO gibi oracle araçlarını kullanmak mümkündür veya Town Crier'ın bir düğüm komitesi (DON gibi) ile birlikte çalışması mahremiyeti korurken Sybil direnişinin çeşitli biçimleri. Kullanıcılar kimlikleri kaydedebilir ve kimlikleri ifşa etmeden benzersiz olduklarına dair kanıt sağlayın. Sybil'e dayanıklı kimlik bilgileri, işlem siparişini zenginleştirmeye yönelik olası bir yaklaşım sunar Sel saldırıları fırsatlarını sınırlayacak politikalar. Örneğin, bir token satış, kayıtlı kullanıcı başına yalnızca bir işleme izin verebilir; kayıt işlemi Sosyal Güvenlik Numarası gibi ulusal bir tanımlayıcının benzersizliğine ilişkin bir kanıt gerektirir. Böyle bir yaklaşım kusursuz değildir ancak işlem baskını saldırılarını azaltmak için yararlı bir politika olabilir.

DON İşlem Yürütme Çerçevesi

(DON-TEF) DONs, oracle ve katman-2 çözümleri için merkezi olmayan kaynak desteği sağlayacaktır. Merkezi Olmayan Oracle Ağ İşlem-Yürütme Çerçevesi (DONTEF) veya kısaca TEF dediğimiz şey. Bugün, DeFi sözleşmelerinin güncelleme sıklığı ana zincir gecikmeleriyle sınırlıdır. örneğin, Ethereum [104] içindeki 10-15 saniyelik ortalama blok aralığı ve ayrıca maliyeti büyük miktarda veriyi zincire aktarma ve sınırlı hesaplama/tx çıktısı — parçalama [148, 158, 232] ve katman-2 yürütme [5, 12, 121, 141, 169, 186, 187]. Çok daha hızlı işlem sürelerine sahip blockchains bile, örneğin [120], zincir dışı hesaplama [168] içeren ölçeklendirme stratejileri önerdiler. TEF'in bu tür herhangi bir katman-1 / MAINCHAIN ​​sistemi için katman-2 kaynağı görevi görmesi amaçlanmaktadır. TEF kullanarak, DONs MAINCHAIN sözleşmesinde daha hızlı güncellemeleri destekleyebilir. Ana zincir tarafından sağlanan temel güven güvencelerinin korunması. TEF destekleyebilir rollups,11 dahil olmak üzere çeşitli katman-2 yürütme teknikleri ve paradigmalarından herhangi biri iyimser rollups, Validium vb. ve ayrıca DON eşik güven modeli düğümler işlemleri yürütür. TEF, FSS'yi tamamlayıcı niteliktedir ve onu desteklemeyi amaçlamaktadır. Başka bir deyişle, herhangi bir TEF'te çalışan uygulama FSS'yi kullanabilir. 11Sıfır bilgi kanıtlarına ihtiyaç duymadıkları için genellikle "zk-rollups" olarak anılırlar, bu yanlış bir isimdir.

6.1 TEF'e Genel Bakış TEF, performanslı bir hibritin inşası ve yürütülmesi için bir tasarım modelidir. smart contract SC. Hibrit smart contracts'nin arkasındaki ana fikre uygun olarak TEF, SC'nin iki parçaya ayrılması: (1) TEF bağlamında çapa dediğimiz şey MAINCHAIN üzerinde SCa sözleşmesi ve (2) DON mantığı, TEF çalıştırılabilirini çağırdığımızı gösterir. SCa'nın birleşimi tarafından uygulanan mantıksal sözleşmeyi belirtmek için burada SC'yi kullanıyoruz. ve bekliyoruz. (Yukarıda belirtildiği gibi, bir diziyi ayrıştırmak için derleyici araçları geliştirmeyi umuyoruz. SC'yi otomatik olarak bu bileşenlere aktarın.) TEF çalıştırılabilir exect, kullanıcıların SC'deki işlemlerini işleyen motordur. o DON üzerinde çalıştığı için performanslı bir şekilde yürütülebilir. Birkaç işlevi vardır: • İşlem alımı: exect, kullanıcıların işlemlerini alır veya getirir. Bunu yapabilir doğrudan, yani DON üzerinden işlem gönderimi yoluyla veya ANA ZİNCİR aracılığıyla MS kullanarak bellek havuzu. • Hızlı işlem yürütme: içindeki varlıkları içeren işlemleri gerçekleştirin SC. Bunu yerel olarak, yani DON üzerinde yapar. • Hızlı ve düşük maliyetli oracle / adaptör erişimi: exect'in oracle raporlarına yerel erişimi vardır ve örneğin daha hızlı, daha ucuz ve daha doğru varlık elde edilmesini sağlayan diğer adaptör verileri MAINCHAIN uygulamasına göre fiyatlandırma. Ayrıca zincir dışı oracle erişimi azalır oracle'in işletme maliyeti, dolayısıyla sistemi kullanma maliyeti, pahalı zincir üstü depolama. • Senkronizasyon: exect periyodik olarak güncellemeleri DON'den MAINCHAIN'e aktararak SCa'yı günceller. Çapa sözleşmesi SC'nin ANA ZİNCİR ön ucudur. SC'nin daha yüksek güvene sahip bileşeni olarak çeşitli amaçlara hizmet eder: • Varlık saklama: Kullanıcıların fonları SCa'ya yatırılır, tutulur ve SCa'dan çekilir. • Senkronizasyon doğrulaması: SCa, çalıştırıldığında durum güncellemelerinin doğruluğunu doğrulayabilir senkronizasyonlar, örneğin rollups'ye eklenen SNARK'lar. • Koruma rayları: SCa, yolsuzluk veya arızalara karşı koruma sağlayacak hükümler içerebilir tam anlamıyla. (Daha fazla ayrıntı için Bölüm 7'ye bakın.) TEF'te, kullanıcıların fonları MAINCHAIN'de saklanmaktadır; bu, DON'nin kendisinin gözetimsiz olduğu anlamına gelir. Senkronizasyon mekanizmasının seçimine bağlı olarak (aşağıya bakın), kullanıcıların DON'ya yalnızca doğru oracle raporlar ve MAINCHAIN ile zamanında senkronizasyon için güvenmek. Ortaya çıkan güven modeli, sipariş defteri tabanlı DEX'lerinkine çok benzer; örneğin [2], Günümüzde genellikle sipariş eşleştirme için zincir dışı bir bileşen ve takas ve ödeme için zincir üstü bir bileşen içerir.Ödeme sistemleri terminolojisini kullanmak gerekirse, exect'i bileşen olarak düşünebiliriz. SC takastan sorumluyken, SCa uzlaşmayı yönetir. Şematik için Şekil 13'e bakınız. TEF'in tasviri. Şekil 13: TEF şeması. Bu örnekte işlemler bellek havuzundan geçiyor MAINCHAIN'in MS aracılığıyla DON adresine. TEF'in faydaları: TEF'in üç ana faydası vardır: • Yüksek performans: SC, DON'nin MAINCHAIN'den çok daha yüksek verimini devralır hem işlemler hem de oracle raporlar için. Ek olarak exect, işlemleri yalnızca MAINCHAIN ​​üzerinde uygulamaya göre daha hızlı işleyebilir ve oracle raporlarına daha zamanında yanıt verebilir. • Daha düşük ücretler: Senkronizasyon işlemi, işlem işlemeye göre zamana daha az duyarlıdır ve işlemler DON'dan MAINCHAIN'e gruplar halinde gönderilebilir. Sonuç olarak, bu yaklaşımla zincir üzerindeki işlem başına ücretler (örneğin gaz maliyetleri), yalnızca MAINCHAIN ​​üzerinde çalışan bir sözleşmeye göre çok daha düşüktür. • Gizlilik: DON'nin gizlilik mekanizmaları, SC'ye devam edin.

TEF sınırlamaları: TEF'in bir sınırlaması, anlık verileri desteklememesidir. para çekme işlemleri, yalnızca ANA ZİNCİRDE gerçekleştiği için: Para çekme talebi gönderildikten sonra SCa'ya, kullanıcının aşağıdakileri içeren bir durum güncellemesi gerçekleştirmesi için exect'i beklemesi gerekebilir: onaylanmadan önce para çekme işlemini gerçekleştirin. Bazı kısmi çözümleri tartışıyoruz. ancak Bölüm 6.2'de. TEF'in diğer bir sınırlaması da DeFi atomik bileşimini desteklememesidir. MAINCHAIN üzerindeki sözleşmeler, özellikle varlıkları birden fazla DeFi üzerinden yönlendirme yeteneği Tek bir işlemde sözleşmeler. Ancak TEF, aralarında böyle bir atomikliği destekleyebilir. DeFi aynı DON üzerinde çalışan sözleşmeler. Ayrıca bu sorunu çözmenin bazı yollarını da tartışıyoruz Bölüm 6.2'deki sorun. 6.2 İşlem Yönlendirme SC işlemleri kullanıcılar tarafından doğrudan DON adresine gönderilebilir veya şu adrese yönlendirilebilir: MAINCHAIN'deki bellek havuzu (FSS aracılığıyla). Dört farklı işlem türü vardır; her biri bunlardan farklı kullanım gerektirenler: Sözleşme içi işlemler: TEF, gaz dinamiğinin komplikasyonlarından kaçındığı için SC'ye işlemleri yönetmede olduğundan daha fazla esneklik sağlıyor katman-1 sözleşmesinde mevcuttur. Örneğin, Ethereum'de bir bellek havuzu işlemi sırasında Daha yüksek gas fiyatına sahip yeni bir işlem üzerine yazılabilir, SC, görünür hale gelir gelmez SC içindeki varlıklar üzerinde çalışan bir işlemi yetkili olarak değerlendirebilir bellek havuzunda. Sonuç olarak, SC'nin bir işlemin onaylanmasını beklemesine gerek yoktur bir blok içinde, bu da gecikmenin önemli ölçüde azalmasına neden olur. Vekillik: Bir kullanıcı bir τ işlemini SC'ye bir cüzdan sözleşmesi yoluyla göndermek isteyebilir veya MAINCHAIN ile ilgili diğer sözleşme. DON'nin aşağıdakilerin yürütülmesini simüle etmesi mümkündür: SC'ye devam eden bir işlemle sonuçlanıp sonuçlanmayacağını belirlemek için MAINCHAIN'de τ. Eğer öyleyse, τ SC için bunu yapan diğer işlemlerle sıralanabilir. Birkaç tane var DON'nin bu tür işlemleri nasıl tanımladığına ilişkin olasılıklar: (1) DON, simüle edebilir bellek havuzundaki tüm işlemler (pahalı bir yaklaşım); (2) Belirli sözleşmeler veya sözleşme türleri, örneğin cüzdanlar, DON tarafından izlenmek üzere listelenebilir; veya (3) Kullanıcılar şunları yapabilir: DON denetimi için işlemlere açıklama ekleyin. Tek bir işlem iki işlemle etkileşime girdiğinde işler daha da karmaşık hale gelir sözleşmeler, SC1 ve SC2, her ikisi de Adil Sıralama Hizmetlerini kullanıyor ve uyumsuz sipariş politikalarına sahip. DON örneğin τ dizisini en geç zamanda sıralayabilir bu her ikisiyle de uyumludur. Mevduat: Bir MAINCHAIN varlığını SC'ye yatıran bir işlemin, SC'nin bunu geçerli olarak değerlendirebilmesi için bir blokta onaylanması gerekir. Bir madenciliği tespit ettiğinde Varlıkları (örneğin Ether) SCa'ya gönderen işlem, anında onaylayabilirmevduat. Örneğin, DON üzerinde oracle tarafından bildirilen güncel bir fiyatı şuna uygulayabilir: varlık. Para çekme işlemleri: Yukarıda belirtildiği gibi TEF'in bir sınırlaması, para çekme işlemlerinin her zaman anında gerçekleştirilememesidir. rollup tipi bir yürütme modelinde, geri çekme Güvenli bir şekilde gerçekleştirilebilmesi için talebin diğer işlemlerle sıralanması, yani özetlenmesi gerekir. işlendi. Ancak bu sınırlamaya yönelik bazı kısmi çözümler mevcuttur. Eğer DON para çekme işlemine kadar rollup geçerlilik kanıtını hızlı bir şekilde hesaplayabiliyorsa, o zaman bir kullanıcının bellek havuzundaki τ işlemini gözlemlemek, τ için daha yüksek bir gaz fiyatında bir durum güncelleme işlemi τ ′ gönderebilir; bu, bir tür faydalı önden çalıştırmadır. τ ′ bellek havuzuna ulaşmadan önce τ'nın çıkarılmaması koşuluyla, τ ′ τ'dan önce gelir ve τ onaylanmış bir çekilme işlemi gerçekleştirecektir. Durum güncellemelerini hesaplamak için DON'ye güvenilen bir TEF varyantında (bkz. aşağıdaki eşik imzalama varyantı), DON alternatif olarak zincir dışını belirleyebilir Yürütülmesi üzerine SC'nin durumu göz önüne alındığında τ'nın onaylanmasının gerekip gerekmediği. DON daha sonra, tam bir işlem gerçekleştirmeden, çekilmeyi onaylayan bir τ ′ işlemi gönderebilir durum güncellemesi. Bu yaklaşımın mümkün olmaması veya başarılı olmadığı durumlarda DON tarafından başlatılan bir τ' işlemi, τ'ye yanıt olarak kullanıcıya para gönderebilir, böylece kullanıcının para göndermesine gerek kalmaz. ek bir işlem başlatın. 6.3 Senkronizasyon TEF yürütülebilir dosyası, güncellemeleri periyodik olarak DON'den MAINCHAIN'e aktarır. senkronizasyon olarak adlandırdığımız bir süreçte SCa'nın durumunun güncellenmesi. Senkronizasyon düşünülebilir katman-2 işlemlerinin katman-1'e yayılması olarak, böylece TEF herhangi bir sayıdan faydalanabilir rollups [5, 12, 16, 69] dahil olmak üzere bu amaca yönelik mevcut tekniklerin sayısı iyimser rollups [10, 11, 141], Validium [201] veya temel eşik imzalama, örneğin eşik BLS, Schnorr veya ECDSA [24, 54, 116, 202]. Prensip olarak güvenilir yürütme ortamları aynı zamanda durum değişikliklerinin doğruluğunu da doğrulayarak çok daha yüksek performans sunar rollups'nin alternatifi, ancak donanıma bağlı bir güven modeliyle. (Bkz. örneğin [80].) Aşağıda bu senkronizasyon seçeneklerini üç temel özelliğe göre karşılaştırıyoruz: TEF: • Veri kullanılabilirliği: SC'nin durumu nerede saklanıyor? En az üç seçenek TEF'te mevcut: MAINCHAIN'de, DON üzerinde veya bazı üçüncü taraf depolama birimlerinde IPFS gibi sağlayıcılar. Farklı güvenlik garantileri, kullanılabilirlik elde ederler seviyeleri ve performans profilleri. Kısaca, MAINCHAIN üzerinde durumun saklanması, zincir üzerinde denetlenebilirlik ve durum kullanılabilirliği için herhangi bir tarafa güvenmeyi ortadan kaldırır; Öte yandan, zincir dışı durumda depolama, depolama maliyetini azaltabilir ve iyileştirmeyi sağlayabilir. depolama sağlayıcılarına (DON veya üçüncü taraflara) güvenme pahasına veri kullanılabilirliği. Elbette bu seçenekleri birleştiren esnek modeller de mümkün. Gerekli veri kullanılabilirliği biçimini Tablo 1'de belirtiyoruz.• Doğruluk garantileri: SCa, güncellemelerin doğruluğunu nasıl tespit eder? exect tarafından mı itildi? Bu, exect ve SCa üzerindeki hesaplama yükünü ve senkronizasyon gecikmesi (aşağıya bakın). • Gecikme: Senkronizasyon gecikmesine katkıda bulunan üç faktör vardır: (1) Geçen süre bir senkronizasyon işlemi oluşturmak için τsync; (2) τsync için geçen süre MAINCHAIN'de onaylanacak; ve (3) τsync'in geçerlilik süresi SCa. TEF'te gecikme, para çekme işlemleri için özellikle önemlidir (ancak para çekme işlemleri için daha az önemlidir). sözleşme içi işlemler) çünkü para çekme işlemleri zorunlu olarak (en azından kısmi) durum senkronizasyonu. Senkronizasyon seçenekler Veri kullanılabilirlik Doğruluk garantiler Gecikme Toplama [5, 12, 16, 69] Zincir üzerinde Geçerlilik kanıtları Oluşturmak için harcanan zaman geçerlilik kanıtları (örneğin mevcut sistemlerdeki dakikalar) Geçerlilik [201] Zincir dışı Geçerlilik kanıtları Yukarıdakiyle aynı İyimser rollup [10, 11, 141] Zincir üzerinde Dolandırıcılık kanıtları Mücadelenin uzunluğu dönem (örneğin, günler veya haftalar) Eşik imzalama [24, 54, 116, 202] Esnek DON imzalarına eşik değeri Anlık Güvenilir yürütme ortamları [80] Esnek Donanım tabanlı tasdikler Anlık Tablo 1: TEF'teki çeşitli senkronizasyon seçenekleri ve bunların özellikleri. Tablo 1, TEF'teki beş ana senkronizasyon seçeneğindeki bu özellikleri özetlemektedir. (Not bu teknolojileri bağımsız katman-2 ölçeklendirmesi olarak karşılaştırma niyetinde olmadığımızı çözümler. Bunun için okuyuculara örneğin [121] adresini öneriyoruz.) Şimdi her senkronizasyon seçeneğini tartışıyoruz. Toplamalar: rollup [69] durum geçişinin bir protokol tarafından gerçekleştirilen bir protokoldür. işlem toplu işlemleri zincir dışında hesaplanır. Durum değişikliği daha sonra yayılır MAINCHAIN'e. rollups'yi uygulamak için, smart contract SCa çapası, gerçek durumun kompakt bir Rstate temsilini (örneğin bir Merkle kökü) saklar. Exect senkronize etmek için τsync = gönderir (T, R' durumu) SCa'ya dönüştürün; burada T, son işlemden bu yana işlediği işlemlerin kümesidir.senkronizasyon ve R′ durum, uygulanarak hesaplanan yeni durumun kompakt temsilidir T'deki işlemleri önceki R durumuna aktarır. SCa'nın τsync'deki durum güncellemelerini doğrulama biçiminde farklılık gösteren iki popüler değişken vardır. İlki, (zk-)rollups, bazen adı verilen kısa ve öz bir doğruluk argümanını ekler. R durumu →R′ geçişi için bir geçerlilik kanıtı devlet. Bu varyantı uygulamak için τsync ile birlikte geçerlilik kanıtını (örneğin zk-SNARK kanıtı) hesaplar ve gönderir, R′ olduğunu kanıtlıyor durum, T'nin SCa'nın mevcut durumuna uygulanmasının sonucudur. Çapa sözleşme, durum güncellemesini ancak kanıtı doğruladıktan sonra kabul eder. İyimser rollup'ler doğruluk argümanlarını içermez ancak staking ve Durum geçişlerinin dağıtılmış doğrulamasını kolaylaştıran prosedürlere meydan okuyun. Bunun için rollup değişkeni, SCa, doğru olduğunu varsayarak geçici olarak τsync'i kabul eder (bu nedenle iyimserlik) ancak τsync, herhangi bir tarafın ANA ZİNCİR'in izlenmesi hatalı durum güncellemelerini tespit edebilir ve SCa'yı alması için bilgilendirebilir gerekli eylemler (örneğin, durumu geri almak ve uygulandığında ceza vermek.) Her iki rollup çeşidi de işlemler yayınlandıkça zincir içi veri kullanılabilirliğine ulaşır Tam durumun oluşturulabileceği zincir üstü. zk-rollups gecikmesi Geçerlilik kanıtlarını oluşturmak için gereken süre, genellikle mevcut sistemlerde dakika sırasına göre [16] ve muhtemelen zaman içinde iyileştirmeler görülecektir. Öte yandan iyimser rollup'lerin gecikme süresi daha yüksektir (ör. günler veya haftalar) çünkü dolandırıcılık kanıtlarının işe yaraması için sorgulama süresinin yeterince uzun olması gerekiyor. Yavaş onaylamanın anlamı incelikli ve bazen şemaya özeldir, dolayısıyla kapsamlı bir analiz kapsam dışındadır. Örneğin, bazı planlar ödemeyi dikkate alır durum güncellemesi onaylanmadan önce işlemler "güvenilmez son" [109] olarak kabul edilir, çünkü normal kullanıcı rollup'yi ANA ZİNCİR'den çok daha hızlı bir şekilde doğrulayabilir. Geçerlilik: Validium, verileri yalnızca zincir dışı olarak kullanılabilir hale getiren bir (zk-)rollup biçimidir ve MAINCHAIN'deki tüm verileri korumaz. Özellikle exect yalnızca yeni olanı gönderir durum ve kanıt ancak SCa'ya yapılan işlemler değil. Validium tarzı senkronizasyonla ve bunu yürüten DON tam durumu saklayan tek taraflardır ve işlemleri yürüten. zk-rollups'de olduğu gibi, senkronizasyon gecikmesine geçerlilik hakimdir kanıt oluşturma süresi. Ancak zk-rollups'den farklı olarak Validium tarzı senkronizasyon, Depolama maliyetini artırır ve verimi artırır. DON tarafından eşik imzası: DON düğüm eşiğinin dürüst olduğunu varsayarsak, basit ve hızlı senkronizasyon seçeneği, DON düğümlerinin toplu olarak yeni durumu imzalamasını sağlamaktır. Bu yaklaşım hem zincir içi hem de zincir dışı veri kullanılabilirliğini destekleyebilir. şunu unutmayın: kullanıcılar DON'ye oracle güncellemeleri için güveniyorlar, kabul etmek için ona daha fazla güvenmeleri gerekmiyor Durum güncellemeleri zaten bir eşik güven modelinde olduğundan. Bir diğer faydası eşik imzalama düşük gecikmelidir. Yeni işlem imza formatları için destek EIP-2938 [70]'de önerilen ve hesap soyutlaması olarak bilinen eşik değerini oluşturur Eşik ihtiyacını ortadan kaldıracağından imzanın uygulanması oldukça kolaylaşır Çok daha karmaşık protokoller içeren ECDSA (örneğin, [116, 117, 118])eşik Schnorr [202] veya BLS [55] imzaları gibi alternatiflerden daha iyidir. Güvenilir Yürütme Ortamları (TEE'ler): TEE'ler, güçlü güvenlik korumaları sağlamayı amaçlayan izole yürütme ortamlarıdır (genellikle donanım tarafından gerçekleştirilir) İçeride çalışan programlar için. Bazı TEE'ler (örn. Intel SGX [84]) kanıt üretebilir, bir çıktının belirli bir program tarafından doğru bir şekilde hesaplandığına dair kanıtlamalar olarak bilinir. belirli bir girdi12. TEF senkronizasyonunun TEE tabanlı bir çeşidi şu şekilde uygulanabilir: Teknikleri kullanarak (zk-)rollups veya Validium'daki kanıtları TEE onaylarıyla değiştirmek [80] adresinden. rollups ve Validium'da kullanılan sıfır bilgi kanıtlarıyla karşılaştırıldığında TEE'ler çok daha fazladır. daha performanslı. Eşik imzalamayla karşılaştırıldığında TEE'ler, eşik imzalamanın karmaşıklığını ortadan kaldırır. Prensipte yalnızca bir TEE olması gerektiğinden eşik ECDSA imzalarının oluşturulması dahil. Ancak TEE'leri kullanmak, donanıma bağlı ekstra güven varsayımlarını beraberinde getirir. Dayanıklılık oluşturmak için TEE'ler eşik imzalamayla da birleştirilebilir TEE örneklerinin bir kısmının tehlikeye atılmasına karşı olmasına rağmen bu koruyucu önlem Eşik ECDSA imzaları oluşturmanın karmaşıklığını yeniden ortaya koyuyor. Ek esneklik: Bu senkronizasyon seçenekleri daha fazla esneklik sağlayacak şekilde aşağıdaki yollarla geliştirilebilir. • Esnek tetikleme: TEF uygulaması, tetiklemenin hangi koşullar altında gerçekleşeceğini belirleyebilir. senkronizasyon tetiklenir. Örneğin, senkronizasyon toplu bazlı olabilir; örneğin, her N işlem, zamana dayalı, örneğin her 10 blokta bir veya olaya dayalı, örneğin gerçekleşir Hedef varlık fiyatları önemli ölçüde hareket ettiğinde. • Kısmi senkronizasyon: Mümkündür ve bazı durumlarda istenir (örneğin, rollups ile, küçük senkronizasyonun hızlı senkronizasyonunu sağlamak için kısmi senkronizasyon gecikmeyi azaltabilir) tam senkronizasyonu belki de yalnızca periyodik olarak gerçekleştiren durum miktarları. Örneğin, exect, kullanıcının SCa'daki bakiyesini güncelleyerek para çekme talebini onaylayabilir ANA ZİNCİR durumunu başka şekilde güncellemeden. 6.4 Yeniden yapılanmalar Ağ istikrarsızlığından ve hatta %51 saldırılarından kaynaklanan Blockchain yeniden yapılanmaları ana zincirin bütünlüğüne tehdit oluşturabilir. Pratikte, rakipler kullandı çifte harcama saldırıları düzenleyecekler [34]. Büyük zincirlere yönelik bu tür saldırılar devam ederken Montajı zor olmasına rağmen bazı zincirler için uygun olmaya devam ediyor [88]. ANA ZİNCİR'den bağımsız olarak çalıştığı için DON ilginç özellikler sunar ile ilişkili yeniden yapılanmalara karşı bazı korumaları gözlemleme ve sağlama olasılığı saldırılar. Örneğin, bir DON, MAINCHAIN'e bağlı bir sözleşmeye (SC) belirli bir eşik uzunluğuna (τ) sahip rakip bir çatalın varlığını rapor edebilir. DON ek olarak şunları da yapabilir: 12Ek ayrıntılar Ek B.2.1'de bulunabilir. Anlamak için bunlara gerek yoktur.

PoW veya PoS ortamında böyle bir çatalın varlığına dair kanıt sağlayın. sözleşme SC, daha fazla işlemin yürütülmesini bir süreliğine askıya almak gibi uygun savunma eylemlerini uygulayabilir (örneğin, borsaların çift harcananları kara listeye almasına izin vermek) varlıklar). %51 saldırısı düzenleyen bir düşmanın sansür isteyebileceğini unutmayın. DON'den gelen raporlara göre, SC'deki bir karşı önlem, İşlemleri (ör. kalp atışı) gerçekleştirmek veya yeni bir rapor talep etmek için DON Yüksek değerli bir işlemi doğrulamak. Bu tür çatallanma uyarıları prensip olarak DON'nin sağlayabileceği genel bir hizmet olsa da Çeşitli amaçlardan herhangi biri için planımız bunları TEF'e dahil etmektir.

Güven Minimizasyonu

Heterojen bir grup kuruluşun katılımıyla merkezi olmayan bir sistem olarak, Chainlink ağı, hem canlılık (kullanılabilirlik) hem de güvenlik (rapor bütünlüğü) açısından hatalara karşı güçlü koruma sağlar. Bununla birlikte, merkezi olmayan sistemlerin çoğu, kendilerini oluşturan bileşenlerin ne ölçüde merkezi olmayan bir yapıya sahip olduğu. Bu madenciler arasında merkezi olmayan yönetimin sınırlı olduğu büyük sistemler için bile geçerlidir [32] ve aracılar [51] uzun süredir mevcut. Herhangi bir merkezi olmayan yönetim çabasının amacı güvenin en aza indirilmesidir: Chainlink ağı içindeki sistemik yolsuzluk veya başarısızlığın olumsuz etkileri, hatta kötü niyetli bir DON nedeniyle. Yol gösterici ilkemiz En Az Ayrıcalık İlkesi [197]'dir. Sistem bileşenleri ve sistem içindeki aktörler, kapsamı kesin olarak belirlenmiş ayrıcalıklara sahip olmalıdır yalnızca kendilerine atanan rollerin başarıyla tamamlanmasına izin vermek. Burada Chainlink'nın kendi yolunda benimsemesi için çeşitli somut mekanizmalar ortaya koyuyoruz giderek daha fazla güven minimizasyonuna doğru. Bu mekanizmaları şu şekilde karakterize ediyoruz: Şekil 14'te gösterilen lokusların, yani köklendikleri sistem bileşenlerinin listesi. her bir lokusa ilgili alt bölümde değinin. 7.1 Veri Kaynağı Kimlik Doğrulaması oracles için mevcut işletim modelleri, az sayıda veri kaynağının bulunması nedeniyle kısıtlanmaktadır. Büyük ölçüde TLS'nin yerel olarak imzalamaması nedeniyle ihmal ettikleri verileri dijital olarak imzalayın veri. TLS, "el sıkışma" protokolünde dijital imzalardan yararlanır (kurmak için) sunucu ve istemci arasında paylaşılan bir anahtar). HTTPS-etkin sunucular bu nedenle sertifikalara sahiptir Prensipte verileri imzalamaya yarayan ortak anahtarlar üzerinde, ancak genellikle kullanılmazlar. bu sertifikalar veri imzalamayı destekler. Sonuç olarak, bir DON'nin güvenliği şu şekildedir: günümüzün oracle ağlarında, bir veriden verileri aslına sadık bir şekilde aktaran oracle düğümlerine dayanır bir sözleşmeye kaynak. Chainlink'de güvenin en aza indirilmesine yönelik vizyonumuzun uzun vadeli önemli bir bileşeni, veri imzalamaya yönelik araç ve standartların desteklenmesi yoluyla daha güçlü veri kaynağı kimlik doğrulamasını içerir. Veri imzalama, uçtan uca bütünlük garantilerinin uygulanmasına yardımcı olabilir. Prensip olarak, eğer bir sözleşme, doğrudan bir veri tarafından imzalanan bir D veri parçasını girdi olarak kabul ediyorsa

Şekil 14: Bu bölümde tartışılan güveni en aza indiren mekanizmaların yerleri. 1⃝Veri kaynaklar, verinin bir fonksiyonunu bağımlıya ileten 2⃝DON'ya veri sağlar 3⃝smart contract. Ek olarak, DON veya oracle ağı 4⃝düğüm içerir MAINCHAIN'deki yönetim smart contracts, örneğin telafi edici düğümler, koruma raylar ve benzeri. kaynak olması durumunda oracle ağı D'yi uygun şekilde kurcalayamaz. Çeşitli teşvik edici OpenID Connect de dahil olmak üzere, verilerin bu şekilde imzalanmasını sağlamaya yönelik çabalar ortaya çıkmıştır. öncelikle kullanıcı kimlik doğrulaması için tasarlanmıştır [9], TLS-N; TLS sertifikalarını ve TLS Kanıt Uzantılarını [63] farklı amaçlarla kullanarak TLS [191]'yi genişletin. OpenID Connect bir miktar benimsenmiş olsa da TLS Kanıt Uzantıları ve TLS-N henüz benimsenmedi. Veri kaynağı kimlik doğrulamasının bir başka potansiyel yolu da yayıncıların kendi kimlik doğrulamasını kullanmaktır. Hızlandırılmış Mobil Sayfalar (AMP) protokolünün [225] parçası olarak içerik dağıtım ağlarında önbelleğe alabilecekleri İmzalı HTTP Değişimleri (SXG) [230]. Chrome mobil tarayıcı, AMP önbelleğe alınmış SXG'lerdeki içeriği, sanki buradan sunuluyormuş gibi görüntüler. önbellek sunucusu alanı yerine yayıncılarının kendi ağ alanları. Bu marka bilinci oluşturma teşviki, CloudFlare'in Gerçek URL'si [83] ve Google'ın ampackager'ı [124] gibi hizmetleri kullanmanın göreceli kolaylığıyla birleştiğinde, önbelleğe alınmış haber içeriğinde SXG'lerin yaygın olarak benimsenmesine yol açabilir; bu da basit, kurcalamaya karşı dayanıklı bir bağlantı sağlar. Chainlink oracles'nin geçerli SXG'lerde bildirilen haber değeri taşıyan olayları tetiklemesinin yolu. Haber yayıncılarının AMP önbelleğe alınmış SXG'leri yüksek tempolu yayınlar için kullanışlı olmayacaktır. Ticaret verileriyle ilgili raporlar gibi uygulamalar, özel işlemler için güvenli bir kaynak olabilir. aşırı hava koşulları veya seçim sonuçları gibi gerçek dünya olaylarıyla ilgili sözleşmeler. Basit dağıtımın, olgun araçların ve esnekliğin hayati öneme sahip olacağına inanıyoruz. veri kaynağı imzalamayı hızlandırma. Veri sağlayıcıların Chainlink düğümlerini şu şekilde kullanmalarına olanak sağlanıyor: kimliği doğrulanmış bir API ön ucu umut verici bir yaklaşım gibi görünüyor. Biz bir yaratma niyetindeyizAğa katılım olsun ya da olmasın, düğümlerin bu modda çalışması seçeneği tam gelişmiş bir oracle olarak. Bu yeteneğe kimliği doğrulanmış veri oluşturma adı veriyoruz (ADO). ADO ile Chainlink düğümleri kullanılarak veri kaynakları yararlanabilecektir Chainlink topluluğunun dijital ekleme konusunda geliştirdiği deneyim ve araçlardan mevcut zincir dışı API paketlerine imzalama yetenekleri. Koşmayı seçmeliler mi düğümleri oracles olarak ek olarak potansiyel yeni gelir akışlarının önünü açabilirler mevcut veri sağlayıcılarla aynı model altında; örneğin Kraken [28], Kaiko [140] ve zincirde API verilerini satmak için Chainlink düğümlerini çalıştıran diğerleri. 7.1.1 Kimliği Doğrulanmış Veri Oluşturmanın Sınırlamaları Veri kaynaklarıyla dijital imzalama, kimlik doğrulamanın güçlendirilmesine yardımcı olsa da, oracle'nin tüm doğal güvenlik veya operasyonel hedeflerini gerçekleştirmek için tek başına yeterli değildir. ağ. Başlangıç olarak, belirli bir veri parçası D'nin yine de sağlam ve zamanında iletilmesi gerekir. bir veri kaynağından smart contract veya başka bir veri tüketicisine giden yol. Yani, hatta tüm verilerin bağımlı olarak önceden programlanmış tuşlar kullanılarak imzalandığı ideal bir ayar sözleşmelerde, verilerin kaynaklardan güvenilir bir şekilde iletilmesi için yine de bir DON gerekli olacaktır sözleşmelere. Ek olarak, sözleşmelerin veya diğer oracle-verilerinin tüketiciler, üzerinden hesaplanan çeşitli işlevlerin doğrulanmış çıktılarına erişmek istiyor iki ana nedenden dolayı kaynak verileri: • Gizlilik: Bir veri kaynağı API'si hassas veya özel veriler sağlayabilir zincirde kamuya açık hale getirilmeden önce düzenlenmesi veya sterilize edilmesi gerekiyor. Ancak imzalı verilerde yapılan herhangi bir değişiklik imzayı geçersiz kılıyordu. Başka bir tane koy Bu durumda, saf ADO ve veri temizleme birbiriyle uyumsuzdur. Örnek 3'te gösteriyoruz bu ikisinin gelişmiş bir ADO biçimi aracılığıyla nasıl uzlaştırılabileceği. • Veri kaynağı hataları: Hem hatalar hem de arızalar veri kaynaklarını etkileyebilir ve dijital imzalar her iki sorunu da çözmez. [98], başlangıcından itibaren Chainlink bu tür hataları düzeltmek için zaten bir mekanizma içeriyordu: artıklık. oracle ağları tarafından yayınlanan raporlar genellikle birden fazla ağ tarafından birleştirilmiş verileri temsil eder kaynaklar. Şimdi, kaynak verilerinin gizliliğini artırmak ve birden çok kaynaktan gelen verileri güvenli bir şekilde birleştirmek için ADO ortamında araştırdığımız şemaları tartışıyoruz. 7.1.2 Gizlilik Veri kaynakları, istenen API'lerin tamamını öngöremeyebilir ve kullanıma sunamayabilir kullanıcılar tarafından. Kullanıcılar özellikle, önceden işlenmiş verilere erişmeyi isteyebilirler. gizlilik. Aşağıdaki örnek sorunu göstermektedir.Örnek 3. Alice, merkezi olmayan bir kimlik (DID) kimlik bilgisi almak istiyor: 18 yaşının üzerinde olduğunu (ve bu nedenle örneğin kredi alabileceğini). yapmak bu nedenle yaşıyla ilgili bu gerçeği bir DID kimlik belgesi veren kuruluşa kanıtlaması gerekiyor. Alice, eyaletinin Motorlu Taşıtlar Dairesi'nin (DMV) verilerini kullanmayı umuyor amaç için web sitesi. DMV'de onun doğum tarihinin bir kaydı var ve bir aşağıdaki biçimde dijital olarak imzalanmış A tasdiki: A = {İsim: Alice, DoB: 02/16/1999}. Bu örnekte, A kanıtı Alice'in DID'ye kanıtlaması için yeterli olabilir. kimlik bilgilerini veren kuruluş 18 yaşından büyük olduğunu söylüyor. Ancak gereksiz yere hassas bilgileri sızdırıyor: Alice'in kesin DoB. İdeal olarak, Alice'in DMV'den istediği şey bunun yerine bir imzadır. “Alice 18 yaşın üzerindedir” şeklindeki basit A′ ifadesi. Başka bir deyişle, istiyor X doğum tarihinde bir G fonksiyonunun çıktısı, burada (gayri resmi olarak), A′ = G(X) = Doğru ise GüncelTarih −X ≥18 yıl; aksi halde G(X) = Yanlış. Genelleme yapmak gerekirse, Alice veri kaynağından imzalı bir talepte bulunabilmek ister. A' formunun tasdiki: A′ = {Ad: Alice, İşlev:G(X), Sonuç: Doğru}, burada G(X), bir G fonksiyonunun ve onun girdi(ler)inin X spesifikasyonunu belirtir. Bir kullanıcının, isteğiyle birlikte girdi olarak istenen G(X)'i sağlayabilmesi gerekir. karşılık gelen kanıt A′. Veri kaynağının A′ onayının G(X) spesifikasyonunu içermesi gerektiğini unutmayın. A′'nın doğru yorumlandığından emin olun. Yukarıdaki örnekte G(X) anlamı tanımlar A'daki Boolean değerinin ve dolayısıyla True'nun tasdikin konusunu ifade ettiği 18 yaşın üzerindedir. Kullanıcının G(X)'i belirtebildiği esnek sorguları işlevsel sorgular olarak adlandırıyoruz. Örnek 3'teki gibi kullanım durumlarının yanı sıra sorgu içeren durumları desteklemek için doğrudan sözleşmelerden, aşağıdakileri içeren işlevsel sorgulara yönelik desteği dahil etmeyi amaçlıyoruz: ADO'nun bir parçası olarak basit G fonksiyonları. 7.1.3 Kaynak Verileri Birleştirme Zincir içi maliyetleri azaltmak için sözleşmeler genellikle birleştirilmiş verileri tüketecek şekilde tasarlanmıştır Aşağıdaki örnekte gösterildiği gibi birden fazla kaynaktan. Örnek 4 (Fiyat verilerinin medyanlaştırılması). Bir fiyat feed'i (ör. bir fiyatın değeri) sağlamak için bir varlık (ör. ETH) diğerine (ör. USD) göre değişirse, bir oracle ağı genellikle Güncel fiyatları borsalar gibi çeşitli kaynaklardan alabilirsiniz. oracle ağı tipik olarak bağımlı bir sözleşmeye SC bu değerlerin medyanını gönderir. Veri imzalamanın olduğu bir ortamda, doğru şekilde çalışan bir oracle ağı elde edilir veri kaynaklarından S = {S1, . . . , SnS} bir değerler dizisi V = {v1, v2, . . . , vnS} itibaren Eşlik eden kaynağa özgü imzalara sahip nS kaynakları Σ = {σ1, σ2, . . . , σnS}. üzerine İmzaları doğrulayarak v = medyan(V) fiyatını SC'ye iletir.Ne yazık ki, bir oracle ağının medyanı iletmesi için basit bir yol yoktur. Örnek 4 ila SC'deki v değeri ve v'nin doğru şekilde hesaplandığına dair kısa ve öz bir σ∗ kanıtı aşırı imzalı girişler. Naif bir yaklaşım, tüm nS veri kaynaklarının genel anahtarlarını SC'de kodlamak olacaktır. oracle ağı daha sonra (V, Σ) aktarır ve SC'nin V'nin medyanını hesaplamasına izin verir. Ancak bu, O(nS) boyutunda bir σ kanıtıyla sonuçlanacaktır; yani σ∗ kısa ve öz olmayacaktır. Bu aynı zamanda tüm imzaların doğrulanması gereken SC için de yüksek gaz maliyetlerine yol açacaktır. Σ. Bunun aksine, SNARK'ların kullanımı, doğru bir şekilde birleştirilmiş, kimliği doğrulanmış kaynak değerlerinin kısa ve öz bir şekilde kanıtlanmasını sağlar. Pratikte uygulanabilir olabilir ancak oldukça yüksek kanıtlayıcıda hesaplama maliyetleri ve zincirde biraz yüksek gaz maliyetleri. Kullanımı Town Crier da bir olasılık ama TEE'lerin kullanımını gerektiriyor, bu da herkese uygun değil kullanıcıların güven modelleri. Kaynaklardan birleştirilmiş verilerin imzalanmasıyla ilgili genel soruna çözümlerin çerçevelenmesine yardımcı olacak yararlı bir kavram, işlevsel imzalar olarak bilinen bir şifreleme aracıdır [59, 132]. Kısaca, işlevsel imzalar, imzalayanın imzalama yeteneğini devretmesine olanak tanır; delege edilen kişi yalnızca imzalayan tarafından seçilen F işlevi aralığındaki mesajları imzalayabilir. Ek D'de bu fonksiyonel kısıtlamanın aralığı sınırlamaya nasıl hizmet edebileceğini gösteriyoruz Veri kaynakları tarafından imzalanan değerlerin bir fonksiyonu olarak DON tarafından yayınlanan rapor değerlerinin yüzdesi. Ayrıca, doğruluk için esnek bir gereklilik içeren, ancak potansiyel olarak çok daha performanslı olan, ayrıklaştırılmış işlevsel imza adı verilen yeni bir ilkel öğeyi de tanıtıyoruz. SNARK'lar gibi yaklaşımlardan daha iyidir. Veri kaynaklarını kaynak kimlik doğrulamasını içerecek şekilde birleştirme sorunu Çıktıların sayısı aynı zamanda CoinCap, CoinMarketCap, CoinGecko gibi veri toplayıcılar için de geçerlidir. Çok sayıda borsadan veri elde eden CryptoCompare vb. bazı durumlarda kamuya açıkladıkları metodolojileri kullanarak hacimlere dayalı ağırlık ve diğer durumlarda tescillidir. Bir değeri yayınlamak isteyen bir toplayıcı Kaynak kimlik doğrulaması, düğümlerin toplanmasıyla aynı zorlukla karşı karşıyadır kaynak verileri. 7.1.4 Kaynak Verilerin İşlenmesi Gelişmiş smart contract'lerin özel toplu istatistiklere bağlı olması muhtemeldir Birçok varlığın yakın zamandaki fiyat geçmişindeki oynaklık gibi birincil veri kaynakları veya ilgili olaylarla ilgili haberlerden metin ve fotoğraflar. DON'de hesaplama ve bant genişliği nispeten ucuz olduğundan, bu istatistikler— Birçok girdiye sahip karmaşık makine öğrenimi modelleri bile, blockchain için belirlenen herhangi bir çıktı değeri yeterince kısa olduğu sürece ekonomik olarak işlenebilir. DON katılımcıların farklı özelliklere sahip olabileceği hesaplama açısından yoğun işler için karmaşık girdilerle ilgili görüşler varsa, sonucu hesaplamadan önce girdiler üzerinde fikir birliğine varmak için DON katılımcıları arasında ekstra iletişim turları gerekebilir. Nihai değer tamamen girdiler tarafından belirlendiği sürece, girdi konsensüsü oluşturulduktan sonra her katılımcı basitçe değeri hesaplayabilir ve bunu diğerine yayınlayabilir.katılımcılara kısmi imzalarını iletebilir veya bunu bir toplayıcıya gönderebilirsiniz. 7.2 DON Güven Minimizasyonu DON bileşenlerine duyulan güveni en aza indirmenin iki ana yolunu öngörüyoruz: yük devretme istemcileri ve azınlık raporları. 7.2.1 Yük Devretme İstemcileri Kriptografi ve dağıtılmış sistemler literatüründeki rakip modeller tipik olarak Bir düğüm alt kümesini bozabilecek (yani tehlikeye atabilecek) bir rakibi düşünün, örneğin, birçok BFT protokolü için üçte birinden azı. Yaygın olarak gözlenir ancak Eğer tüm düğümler aynı yazılımı çalıştırıyorsa, ölümcül bir istismarı tespit eden bir düşman, prensip olarak tüm düğümleri aşağı yukarı aynı anda tehlikeye atar. Bu ayar sıklıkla yazılım monokültürü olarak anılır [47]. Sorunu çözmek için yazılım ve yazılım konfigürasyonlarının otomatik olarak çeşitlendirilmesine yönelik çeşitli öneriler ortaya konmuştur, örneğin [47, 113]. [47]'de belirtildiği gibi, ancak yazılım çeşitliliği karmaşık bir konudur ve dikkatli bir değerlendirme gerektirir. Örneğin yazılım çeşitlendirmesi monokültürden daha kötü güvenlikle sonuçlanabilir. bir sistemin saldırı yüzeyini ve dolayısıyla olası saldırı vektörlerini aşan artırır sunduğu güvenlik avantajları. Güçlü yük devretme istemcilerine, yani düğümlerin bağlanacağı istemcilere yönelik desteğin olduğuna inanıyoruz. felaket niteliğinde bir olay karşısında geçiş yapabilir - özellikle çekici bir yöntemdir yazılım çeşitlendirmesi Yük devretme istemcileri potansiyel vektörlerin sayısını artırmaz Ana hat yazılımı olarak konuşlandırılmadıkları için saldırılara karşı koruma sağlarlar. Açık faydalar sunarlar, ancak ikinci savunma hattı olarak. DONs'deki yük devretme istemcilerini şu şekilde desteklemeyi amaçlıyoruz: tek bir istemciye güvenliğe bağımlılıklarını azaltmanın önemli bir yoludur. Chainlink zaten güçlü bir yük devretme istemcileri sistemine sahiptir. Yaklaşımımız önceki, savaşta test edilmiş istemci sürümlerinin korunmasını içerir. Bugün, örneğin, birincil istemcileri Zincir Dışı Raporlama (OCR) olan Chainlink düğümler destek içerir gerekirse Chainlink’nın önceki FluxMonitor sistemi için. Bazıları için kullanılıyordu FluxMonitor zamanla güvenlik denetimlerinden ve saha testlerinden geçmiştir. Aynısını sağlar OCR gibi işlevsellik, yalnızca daha yüksek maliyetle; yalnızca ihtiyaç duyulduğunda ortaya çıkan bir maliyet. 7.2.2 Azınlık Raporları Yeterince büyük bir azınlık kümesi Ominority (çoğunluğun suiistimallerini gözlemleyen dürüst düğümlerin bir kısmı) göz önüne alındığında, bir azınlık oluşturmaları onlara yardımcı olabilir. rapor et. Bu, zincirdeki SC'ye bağlı bir sözleşmeye aktarılan paralel bir rapor veya işarettir. Ominority tarafından. SC bu bayrağı kendi sözleşmeye özel politikasına göre kullanabilir. Örneğin, güvenliğin canlılık veya yanıt verebilirlikten daha önemli olduğu bir sözleşme için azınlık raporu, sözleşmenin ek raporlar talep etmesine neden olabilir. başka bir DON'dan bağlayın veya bir devre kesiciyi tetikleyin (sonraki bölüme bakın).Azınlık raporları, çoğunluk dürüst olsa bile önemli bir rol oynayabilir. çünkü herhangi bir rapor toplama şeması, işlevsel imzalar kullanıyor olsa bile, oracle veya veri arızasına karşı dayanıklılık sağlamak için eşik şeklinde çalışır. içinde Başka bir deyişle, girdilere dayalı olarak geçerli bir rapor üretmek mümkün olmalıdır. kS < nS oracles, bazı kS eşikleri için. Bu, bozuk bir DON dosyasında bazı şeylerin olduğu anlamına gelir arasından tercih edilen kS değerlerini seçerek rapor değerlerini değiştirme özgürlüğü Tüm kaynaklar dürüst olsa bile, V'de tam oracles kümesi tarafından bildirilen nS. Örneğin, fonksiyonel bir sistem kullanan bir sistemde nS = 10 ve kS = 7 olduğunu varsayalım. ETH'nin USD fiyatı için V üzerinden medyanın hesaplanmasını doğrulamak için imza. Beş kaynağın \(500, while the other five report \)1000 tutarında bir fiyat bildirdiğini varsayalım. Daha sonra, en düşük 7 raporun medyanlaştırılması yoluyla DON geçerli bir v = 500 $ değeri çıkarabilir, ve en yüksek olanı medyanlaştırarak v = 1000$ çıktısını alabilir. DON protokolünü geliştirerek tüm düğümlerin hangi verinin kaydedildiğini bilmesini sağlayarak mevcut olup olmadığı ve bir rapor oluşturmak için hangi verilerin kullanıldığı dikkate alındığında, düğümler tespit edip işaretleyebilir Bir rapor grubunu diğerine tercih etme ve sonuç üretme yönünde istatistiksel olarak anlamlı eğilimler sonuç olarak bir azınlık raporu. 7.3 Koruma Rayları DONs için güven modelimiz, ANA ZİNCİR'i daha yüksek güvenlikli, daha yüksek ayrıcalıklı olarak ele alır DONs'den daha fazla sistem. (Bu güven modeli her zaman geçerli olmasa da daha kolaydır ortaya çıkan mekanizmayı DON'nin daha yüksek güvenlik olduğu durumlara uyarlamak için platform tam tersidir.) Dolayısıyla doğal bir güven minimizasyon stratejisi, smart contracts'de (ya bir MAINCHAIN ön ucunda) izleme ve arıza güvenliği mekanizmalarının uygulanmasını içerir DON için veya doğrudan bağımlı bir sözleşme SC'sinde. Bu mekanizmaları şöyle adlandırıyoruz: Korkulukları inceleyin ve en önemlilerinden bazılarını burada sıralayın: • Devre kesiciler: SC, durum güncellemelerinin kendi özelliklerinin bir fonksiyonu olarak durum güncellemelerini duraklatabilir veya durdurabilir (örneğin, sıralı güncellemeler arasındaki büyük fark). raporlar) veya diğer girdilere dayalı olarak. Örneğin bir devre kesici devreye girebilir oracle raporlarının zaman içinde inanılmaz derecede değiştiği durumlar. Bir devre kesici olabilir aynı zamanda bir azınlık raporuna da takılıp kalacak. Böylece devre kesiciler DONs'yi engelleyebilir Büyük ölçüde hatalı raporlar hazırlamaktan. Devre kesiciler ek müdahalelerin dikkate alınması için zaman sağlayabilir veya egzersiz yaptı. Bu tür müdahalelerden biri kaçış kapaklarıdır. • Kaçış kapakları: Bir grup emanetçi, topluluk token sahipleri veya diğer mütevelli heyeti tarafından belirlenen olumsuz koşullar altında, bir sözleşmeye başvurulabilir bazen kaçış kapısı olarak adlandırılan bir acil durum tesisi [163]. Bir kaçış kapısı SC'nin bir şekilde kapanmasına neden olur ve/veya beklemeyi sonlandırır ve muhtemelen gelecekteki işlemler. Örneğin, saklanan fonları [17] kullanıcılarına iade edebilir),sözleşme şartlarını [162] feshedebilir veya bekleyen ve/veya gelecekteki işlemleri [173] iptal edebilir. Kaçış kapakları yalnızca herhangi bir sözleşme türünde kullanılabilir. DON'ye dayanan, ancak bunlara karşı potansiyel bir tampon olarak ilgi çekicidirler DON görevi kötüye kullanma. • Yük devretme: SC'nin temel hizmetler için DON'ye güvendiği sistemlerde, SC'nin hizmetin devamını sağlayan yük devretme mekanizmaları sağlaması mümkündür. DON hatası veya hatalı davranış durumunda. Örneğin, TEF'te (Bölüm 6), çapa sözleşmesi SCa, hem zincir üzerinde hem de zincir üzerinde ikili arayüzler sağlayabilir. Zincir dışı yürütme arayüzleri belirli kritik işlemler için desteklenir (ör. para çekme) veya sıradan işlemler için, DON işlemlerin önden yürütülmesini önlemek için uygun bir gecikmeyle. Veri kaynaklarının verileri imzaladığı durumlarda kullanıcılar ayrıca DON başarısız olduğunda SCa'ya rapor sunacaktır. Çeşitli iyimser rollup biçimleri için önerildiği gibi sahtekarlık kanıtları (bkz. Bölüm 6.3), Yukarıda saydığımız mekanizmalara benzer ve tamamlayıcı niteliktedirler. onlar aynı zamanda bir tür zincir içi izleme ve potansiyel arızalara karşı koruma sağlar. zincir dışı sistem bileşenleri. 7.4 Güveni En Aza İndirilmiş Yönetişim Tüm merkezi olmayan sistemler gibi, Chainlink ağı da yönetim mekanizmaları gerektirir zaman içinde parametreleri ayarlamak, acil durumlara müdahale etmek ve gelişimini yönlendirmek için. Bu mekanizmaların bazıları şu anda MAINCHAIN üzerinde bulunmaktadır ve varlığını sürdürmeye devam edebilir. DONs dağıtımında bile bunu yapın. Bir örnek ödeme mekanizmasıdır oracle düğüm sağlayıcıları için (DON düğümler). DON MAINCHAIN'de ön uç sözleşmeleri Periyodik değişikliklere tabi olabilecek korkuluklar gibi ek mekanizmalar içerir. değişiklik. İki sınıf yönetim mekanizması öngörüyoruz: evrimsel ve acil durum. Evrimsel yönetim: Chainlink ekosisteminde yapılan birçok değişiklik öyle ki bunların uygulanması acil bir konu değil: Performans iyileştirmeleri, özellik geliştirmeleri, (acil olmayan) güvenlik yükseltmeleri vb. Chainlink giderek daha fazla katılımcıya doğru ilerledikçe, daha fazla katılımcı bekliyoruz bu tür değişikliklerin çoğu, belirli bir DON topluluğu tarafından onaylanacak ve bu değişikliklerden etkilenenler değişiklikler. Bu arada ve belki de sonuçta paralel bir mekanizma olarak inanıyoruz ki geçici en az ayrıcalık kavramının, evrimsel yönetimi uygulamanın yararlı bir yolu olabileceği. Çok basit bir şekilde fikir, değişikliklerin kademeli olarak dağıtılması ve topluluğa onlara yanıt verme fırsatı verir. Örneğin yeni bir yere geçiş MAINCHAIN sözleşmesi, yeni sözleşmenin uygulanmasını gerektirecek şekilde kısıtlanabilir aktivasyondan en az otuz gün önce.Acil durum yönetimi: MAINCHAIN'deki istismar edilebilir veya istismar edilen güvenlik açıkları sözleşmeler veya diğer canlılık veya güvenlik başarısızlıkları, felaketle sonuçlanabilecek sonuçlara karşı önlem almak için acil müdahale gerektirebilir. Amacımız çoklu imzayı desteklemek Herhangi bir kuruluşun suiistimal etmesini önlemek için müdahale mekanizması, İmzacılar çeşitli kuruluşlara dağıtılacak. İmzalayanların tutarlı kullanılabilirliğini sağlamak ve acil durum yetkilendirmesi için uygun komuta zincirlerine zamanında erişim Değişiklikler açıkça dikkatli operasyonel planlama ve düzenli inceleme gerektirecektir. Bunlar zorluklar, diğer siber güvenlik olay-müdahale testlerinde yer alan zorluklara benzer yetenekler [134], dikkatin azaltılması [223] gibi yaygın sorunlarla mücadele etme ihtiyacına benzer. DONs'nin yönetimi, birçok merkezi olmayan sistemden farklıdır. potansiyel heterojenlik derecesi. Her DON farklı veri kaynaklarına, yürütülebilir dosyalara, çalışma süresi gibi hizmet düzeyi gereksinimlerine ve kullanıcılara sahip olabilir. Chainlink ağının Yönetişim mekanizmaları bu tür farklılıklara uyum sağlayacak kadar esnek olmalıdır. Operasyonel hedefler ve parametreler. Tasarım fikirlerini aktif olarak araştırıyoruz ve planlıyoruz. Gelecekte bu konuyla ilgili araştırma yayınlayın. 7.5 Açık Anahtar Altyapısı Aşamalı ademi merkeziyetçilik ile birlikte, güçlü bir tanımlama ihtiyacı ortaya çıkacaktır. DON düğümleri dahil olmak üzere ağ katılımcıları. Özellikle, Chainlink güçlü bir kod gerektirir Açık Anahtar Altyapısı (PKI). PKI, anahtarları kimliklere bağlayan bir sistemdir. için Örneğin, bir PKI İnternet'in güvenli bağlantı sistemini (TLS) destekler: HTTPS (ör. https://www.chainlinklabs.com) aracılığıyla bir web sitesine bağlanırsınız ve kilit tarayıcınızda görünüyor; bu, alan adı sahibinin ortak anahtarının olduğu anlamına gelir. söz konusu sahibine bir otorite tarafından, özellikle de dijital bir imza yoluyla bağlanmış olması sözde sertifika. Üst düzey kök yetkilileri popüler tarayıcılarla bağlantılı olan hiyerarşik bir sertifika yetkilileri (CA) sistemi, sertifikaların yalnızca alan adlarının meşru sahiplerine verilir. Chainlink öğesinin eninde sonunda merkezi olmayan ad hizmetlerinden yararlanmasını bekliyoruz. başlangıçta PKI'mızın temeli olarak Ethereum Ad Hizmeti (ENS) [22]. olarak adından da anlaşılacağı üzere ENS, haritaları alan Alan Adı Sistemi olan DNS'ye benzer. (insan tarafından okunabilen) alan adlarını internetteki IP adreslerine aktarır. Ancak ENS bunun yerine insanlar tarafından okunabilen Ethereum adlarını blockchain adreslerle eşler. Çünkü ENS Ethereum blockchain üzerinde çalışıyor, anahtarların ele geçirilmesini engelliyor, Ad alanı prensip olarak onu yöneten sözleşmeyi tahrif etmek kadar zordur ve/veya temeldeki blockchain. (DNS, bunun tersine, tarihsel olarak savunmasızdı sahtecilik, korsanlık ve diğer saldırılara karşı.) data.eth'i Ethereum ana ağında ENS'ye kaydettik ve şunları yapmayı planlıyoruz: bunu, altında oracle veri hizmetlerinin kimliklerinin yer aldığı bir kök ad alanı olarak oluşturun ve diğer Chainlink ağ varlıkları bulunur. ENS'deki alanlar hiyerarşiktir, yani her alan adı referans içerebilir altındaki diğer isimlere. ENS'deki alt alanlar, düzenleme ve düzenlemenin bir yolu olarak hizmet edebilir.güveni devredin. Data.eth'in ana rolü, zincir üstü bir dizin hizmeti olarak hizmet etmek olacaktır. veri beslemeleri. Geleneksel olarak, oracles geliştiricileri ve kullanıcıları zincir dışı kaynakları kullanırdı (ör. docs.chain.link veya data.chain.link gibi web siteleri veya Twitter) oracle veri akışı adreslerini (ETH-USD fiyatı gibi) yayınlamak ve almak için besleme). data.eth gibi son derece güvenilir bir kök ad alanıyla, bunun yerine eth-usd.data.eth'in örneğin smart contract adresiyle eşleştirilmesi mümkündür. ETH-USD fiyat akışı için zincir içi bir oracle ağ toplayıcının. Bu herkesin gerçeğin kaynağı olarak blockchain'ye başvurabileceği güvenli bir yol oluşturun söz konusu fiyat/isim çiftinin (ETH-USD) veri akışı. Sonuç olarak, ENS'nin bu şekilde kullanılması zincir dışı veri kaynaklarında bulunmayan iki avantajın farkına varır: • Güçlü güvenlik: Etki alanındaki tüm değişiklikler ve güncellemeler değişmez bir şekilde kaydedilir ve bir web sitesindeki metin adreslerinin aksine kriptografik olarak güvence altına alınmıştır. bu iki güvenlik özelliğinden hiçbirinden yararlanamazsınız. • Zincir içi otomatik yayılma: Bir veri akışının smart contract temel adresinde yapılan güncellemeler, bağımlı akıllıya yayılan bildirimleri tetikleyebilir sözleşmeler ve örneğin bağımlı sözleşmeleri otomatik olarak güncelleyebilir yeni adresler.13 Ancak ENS gibi ad alanları meşru sahipliği otomatik olarak doğrulamaz ileri sürülen isimlerden. Bu nedenle, örneğin ad alanı girişi içeriyorsa ⟨“Acme Oracle Node Co.”, addr⟩, daha sonra kullanıcı, adresin Acme adını talep eden kişiye ait olduğu güvencesini elde eder Oracle Node Co. Ad alanı yönetimine ilişkin ek mekanizmalar olmadan, ancak ismin yasal olarak bir kuruluşa ait olduğuna dair güvence elde edemez Acme Oracle Node Co.'yu gerçek dünya anlamında anlamlı bir şekilde adlandırdı. İsimlerin doğrulanmasına yönelik yaklaşımımız, yani bunların ilgili, meşru gerçek dünya varlıkları tarafından sahiplenilmesini sağlamak, çeşitli bileşenlere dayanır. Bugün, Chainlink Laboratuvarlar Chainlink ağı için etkili bir şekilde CA görevi görür. Chainlink Laboratuvarlar devam edecek İsimleri doğrulamak için PKI'mız iki şekilde daha merkezi olmayan bir modele dönüşecektir: • Güven ağı modeli: Hiyerarşik bir PKI'nın merkezi olmayan karşılığına genellikle güven ağı denir.14 1990'lardan bu yana farklı seçenekler önerilmiştir, örneğin [98] ve bazı araştırmacılar blockchains'nin, sertifikaları küresel olarak tutarlı bir şekilde kaydederek [227] gibi fikrin kullanımını kolaylaştırabileceğini gözlemledi. defter. Varlıkların kimliklerini doğrulamak için bu modelin varyantlarını araştırıyoruz Chainlink ağında daha merkezi olmayan bir şekilde. 13A bağımlı sözleşme, isteğe bağlı olarak, manuel incelemeye izin vermek için önceden belirlenmiş bir gecikme içerebilir ve bağımlı sözleşme yöneticilerinin müdahalesi. 14PGP [238] için Phil Zimmermann tarafından türetilen bir terim.• Verilerin doğrulanmasıyla bağlantı: Bugün, önemli miktarda oracle düğüm performansı verisi zincir üzerinde görülebilmektedir ve dolayısıyla arşivsel olarak düğüm adreslerine bağlanmıştır. Bu tür veriler, ağa (güvenilir) katılımının tarihsel kanıtını sağlayarak PKI'daki kimliği zenginleştiriyor olarak görülebilir. Ek olarak araçlar DECO ve Town Crier [160] etkinleştirme düğümlerine dayalı merkezi olmayan kimlik için gerçek dünya verilerinden elde edilen kimlik bilgilerini toplamak için. Sadece bir örnek olarak, bir düğüm operatörü, PKI kimliğine sahip olduğunu kanıtlayan bir kimlik bilgisi ekleyebilir Dun ve Bradstreet derecelendirmesine göre. Bu tamamlayıcı doğrulama biçimleri, Ağ güvenliğinin güvencesini oluştururken staking ekini kullanın. Yerleşik bir gerçek dünya kimliğine sahip bir oracle düğümü hisse sahibi olarak görülebilir itibarından kaynaklanan bir sistemde. (Bkz. Bölüm 4.3 ve Bölüm 9.6.3.) Chainlink PKI için son gereksinim güvenli önyüklemedir, yani güvenli bir şekilde Chainlink ağının kök adını yayınlıyor, şu anda data.eth (benzer şekilde) tarayıcılarda üst düzey etki alanlarının donanımsal bağlantısına kadar). Başka bir deyişle, Chainlink kullanıcıları nasıl data.eth'in gerçekten Chainlink ile ilişkili üst düzey alan adı olup olmadığını belirleyin proje? Chainlink ağı için bu sorunun çözümü çok yönlüdür ve şunları içerebilir: • Chain.link için etki alanı kaydımıza şunu belirten bir [224] TXT kaydı ekleme data.eth'i Chainlink ekosisteminin kök alanı olarak kullanın. (Chainlink dolayısıyla kök ENS alanını doğrulamak için internet alan adları için PKI'dan dolaylı olarak yararlanır.) • Chainlink adlı kişinin mevcut web sitesinden data.eth'e bağlantı verme (ör. https://docs.chain.link. (PKI'nın internet alanları için başka bir örtülü kullanımı.) • Bu teknik inceleme de dahil olmak üzere çeşitli belgeler aracılığıyla data.eth'in kullanımının duyurulması. • Twitter gibi sosyal medya kanallarımızda data.eth'i herkese açık olarak yayınlamak ve Chainlink blogu [18]. • Büyük miktarda LINK'in aynı tescil ettiren adresinin kontrolü altına alınması data.eth olarak

DON Dağıtımda Dikkat Edilmesi Gerekenler

Temel tasarımımızın bir parçası olmasa da, birkaç önemli teknik husus vardır. burada tedaviyi hak eden DON'lerin farkına varılması.

8.1 Kullanıma Sunma Yaklaşımı Bu belge, gelişmiş Chainlink işlevselliğine ilişkin iddialı bir vizyon ortaya koymaktadır. gerçekleştirme, yol boyunca birçok zorluğa çözüm gerektirecektir. Bu teknik inceleme bazı zorlukları tanımlar, ancak öngörülemeyenlerin ortaya çıkacağı kesindir. Bu vizyonun unsurlarını kademeli olarak uzun bir süre boyunca uygulamayı planlıyoruz. uzatılmış zaman dilimi. Beklentimiz, DONs'nin başlangıçta şu şekilde piyasaya sürülmesidir: ekipler tarafından ortaklaşa oluşturulan belirli önceden oluşturulmuş bileşenler için destek Chainlink topluluk. Amaç, DONs'nin daha geniş şekilde kullanılmasıdır; örneğin, isteğe bağlı yürütülebilir dosyaları başlatın, daha sonra destek göreceksiniz. Bu tür dikkatli olmanın bir nedeni, smart contract'ların bileşiminin son dönemdeki flaş kredi tabanlı saldırılarda olduğu gibi karmaşık, istenmeyen ve tehlikeli yan etkilere sahip olabilmesidir. örneğin gösterilmiştir [127, 189]. Benzer şekilde, smart contract'lerin, bağdaştırıcıların ve yürütülebilir dosyalar aşırı dikkat gerektirecektir. DONs'nin ilk dağıtımında, yalnızca önceden oluşturulmuş şablon haline getirilmiş yürütülebilir dosyalar ve bağdaştırıcılar kümesini dahil etmeyi planlıyoruz. Bu, bileşimsel güvenliğin incelenmesine olanak sağlayacaktır. Bu işlevlerin resmi yöntemler [46, 170] ve diğer yaklaşımlar kullanılarak belirlenmesi. Olacak aynı zamanda fiyatlandırmayı da basitleştirir: İşlevsellik fiyatlandırması, benimsenen bir yaklaşım olan genelleştirilmiş ölçüm yerine DON düğümleri tarafından işlevsellik esasına göre belirlenebilir. örneğin [156]. Ayrıca Chainlink topluluğunun da oluşturma sürecine katılmasını bekliyoruz çeşitli bağdaştırıcıları ve yürütülebilir dosyaları giderek daha fazla bir araya getiren ek şablonlar Binlerce olmasa da yüzlerce kişi tarafından çalıştırılabilen kullanışlı merkezi olmayan hizmetler DONs. Ek olarak, bu yaklaşım durum şişkinliğini, yani DON ihtiyacını önlemeye yardımcı olabilir. düğümlerin çalışma belleğinde çalışılamaz miktarda durumu tutmasını sağlar. Bu sorun zaten izinsiz blockchains'de ortaya çıkıyor, "durumsuz" gibi motive edici yaklaşımlar istemciler” (bkz. örneğin [206]). Daha yüksek verimli sistemlerde daha şiddetli olabilir, motive edicidir. DON öğesinin yalnızca durum boyutu optimize edilmiş yürütülebilir dosyaları dağıttığı bir yaklaşım. DON'ler gelişip olgunlaştıkça ve Bölüm 7'de tartışıldığı gibi sağlam koruma raylarını, Bölüm 9'da tartışıldığı gibi kriptoekonomik ve itibara dayalı güvenlik mekanizmalarını ve DON kullanıcıları için yüksek derecede güvence sağlayan diğer özellikleri içerdikçe, biz de ayrıca, daha geniş çapta lansmanı ve kullanımı kolaylaştıracak bir çerçeve ve araçlar geliştirmeyi bekliyoruz. DONs topluluk tarafından. İdeal olarak, bu araçlar bir dizi düğüm operatörüne olanak tanıyacaktır. bir oracle ağı olarak bir araya gelip kendi DON'lerini izinsiz bir şekilde başlatmak veya self-servis şekilde, yani bunu tek taraflı olarak yapabilirler. 8.2 Dinamik DON Üyelik Belirli bir DON çalıştıran düğüm kümesi zaman içinde değişebilir. İki yaklaşım var O'da dinamik üyelik verildiğinde skL'nin kilit yönetimine. Bunlardan ilki, üyelik değişiklikleri üzerine düğümlerin elinde bulunan skL paylarını güncellemektir. pkL'yi değiştirmeden tutarken. [41, 161, 198]'de incelenen bu yaklaşımın haklılığı vardır. güvenen tarafların pkL'yi güncellemesinin gerekmemesi.[122]'de tanıtılan klasik paylaşım yeniden paylaşımı tekniği, basit bir ve bu tür paylaşım güncellemelerini gerçekleştirmenin etkili bir yolu. Bir sırrın aktarılmasını sağlar bir O(1) düğüm kümesi ile bir ikinci düğüm arasında, muhtemelen bir O(2) ile kesişiyor. bunda yaklaşım, her düğüm O(1) ben gizli paylaşımının (k(2), n(2)) gizli paylaşımını gerçekleştirir n(2) = |O(2)| için O(2)'deki düğümler ve arzu edilen (muhtemelen yeni) eşik k(2). Çeşitli doğrulanabilir gizli paylaşım (VSS) şemaları [108], bir düşmana karşı güvenlik sağlayabilir Düğümleri aktif olarak bozar, yani protokole kötü niyetli davranışlar sokar. [161]'deki teknikler, iletişim karmaşıklığını azaltırken ve kriptografik sertlik varsayımlarındaki hatalara karşı dayanıklılık. İkinci bir yaklaşım ise genel muhasebe anahtarı pkL'yi güncellemektir. Bunun ileri gitme avantajı var güvenlik: PkL'nin eski hisselerinden (yani eski komite düğümlerinden) ödün verilmesi geçerli anahtarın tehlikeye girmesiyle sonuçlanır. Ancak pkL'ye yapılan güncellemeler iki dezavantaja sahiptir: (1) pkL altında şifrelenen verilerin, anahtar yenileme sırasında yeniden şifrelenmesi gerekir ve (2) Önemli güncellemelerin güvenen taraflara yayılması gerekir. Her iki yaklaşımın yanı sıra ikisinin melezleşmelerini de keşfetmeyi amaçlıyoruz. 8.3 DON Sorumluluk Mevcut Chainlink oracle ağlarda olduğu gibi, DON'ler hesap verebilirlik mekanizmaları içerecektir; yani doğru düğüm davranışını kaydetme, izleme ve uygulama. DONs sahip olacak mevcut birçok izinsiz blockchain'den çok daha önemli veri kapasitesi, özellikle harici merkezi olmayan depolamaya bağlanma yetenekleri göz önüne alındığında. Sonuç olarak, düğümlerin performans geçmişini ayrıntılı olarak kaydedebilecekler. daha ince taneli hesap verebilirlik mekanizmaları. Örneğin, zincir dışı hesaplama varlık fiyatları, medyan sonuç gönderilmeden önce atılan girdileri içerebilir. zincir. Bir DON'de bu ara sonuçlar kaydedilebilir. Bir DON içindeki bireysel düğümlerin hatalı davranışları veya performans düşüşleri böylece giderilebilir veya cezalandırılabilir. DON ince taneli bir şekilde. Ayrıca inşaat yaklaşımlarını da tartıştık. Bölüm 7.3'te sistemik arızaların sözleşmeye özel etkilerini ele alan korkuluklar. Bununla birlikte, DON'lerin kendileri için arıza güvenliği mekanizmalarına sahip olmak da önemlidir. yani sistemik, potansiyel olarak yıkıcı DON arızalara karşı korumalar, özellikle Şimdi açıklayacağımız gibi çatallanma/kaçırma ve hizmet düzeyi anlaşması (SLA) başarısızlıkları. Çatallama / kaçamaklık: Yeterli sayıda hatalı düğüm göz önüne alındığında, bir DON çatallanabilir veya L'de iki farklı, tutarsız blok veya blok dizisi üreterek kaçamaklılık. Ancak DON L'nin içeriğini dijital olarak imzaladığından, Kaçırmayı önlemek ve/veya cezalandırmak için ana zincir ANA ZİNCİR. DON, MAINCHAIN ​​üzerindeki bir denetim sözleşmesindeki L'nin durumunu periyodik olarak kontrol edebilir. Gelecekteki durumu kontrol noktası durumundan saparsa kullanıcı/denetçi kanıt sunabilir Denetim sözleşmesine yönelik bu hatalı davranışın Böyle bir kanıt bir uyarı oluşturmak için kullanılabilir veya sözleşmede kesinti yaparak DON düğümü cezalandırın. Bu sonuncu yaklaşım şunu tanıtıyor: belirli oracle feed'lerine benzer bir teşvik tasarımı sorunudur ve bunun üzerine inşa edilebilir Çalışmamız Bölüm 9'da özetlenmiştir.Hizmet düzeyi anlaşmalarının uygulanması: DONs mutlaka şu anlama gelmese de süresiz olarak çalıştırıldığından hizmet düzeyi anlaşmalarına (SLA'lar) uymaları önemlidir kullanıcılarıyla birlikte. Ana zincirde temel SLA uygulaması mümkündür. Örneğin, DON düğümleri, DON'yi belirli bir tarihe kadar sürdürmeyi veya hizmetin sonlandırılmasına ilişkin önceden bildirimde bulunmayı (ör. üç aylık bildirim) taahhüt edebilir. Bir sözleşme MAINCHAIN temel kriptoekonomik SLA uygulamasını sağlayabilir. Örneğin, kontrol noktalarının kapalı olması durumunda SLA sözleşmesi DON yatırılan parayı kesebilir. gerekli aralıklarla verilmemektedir. Bir kullanıcı para yatırabilir ve DON'ye meydan okuyabilir bir kontrol noktasının bir dizi geçerli blok dizisini doğru şekilde temsil ettiğini kanıtlamak (bir bakıma örneğine benzer; [141]). Elbette blok üretimi işlemle eş anlamlı değil ancak SLA sözleşmesi aynı zamanda ikincisinin uygulanmasına da hizmet edebilir. Örneğin, İşlemlerin bellek havuzundan alındığı (bkz. Bölüm 5.2), FSS'nin eski uyumlu sürümü, işlemlerin sonunda çıkarıldığı ve zincire yerleştirildiği. Bir kullanıcı SLA sözleşmesini aşağıdaki gibi bir işlemle sunarak DON suiistimali kanıtlayabilir: DON tarafından çıkarıldı ancak hedef sözleşmeye göre işlenmek üzere iletilmedi uygun zaman aralığında.15 Daha ince taneli SLA'ların varlığını kanıtlamak ve cezalandırmak da mümkündür. yürütülebilir dosyaları kullanan hesaplama hataları da dahil olmak üzere hatalar (örneğin, mekanizmalar aracılığıyla) Bölüm 6.3'te belirtilen zincir dışı durum işlemlerinin doğru olduğunu kanıtlamak için) veya çalıştırılamaması DON üzerinde görünen başlatıcılara dayalı yürütülebilir dosyalar, DON üzerindeki verilerin aktarılamaması ANA ZİNCİRİ zamanında vb.

Ekonomi ve Kriptoekonomi

Chainlink ağının merkezi olmayan bir güven modeli içerisinde güçlü bir güvenliğe ulaşması için, Düğümlerin kolektif olarak doğru davranışı sergilemesi, yani bağlı kalmaları önemlidir. çoğu zaman tam olarak DON protokollerine göre. Bu bölümde yaklaşımları tartışıyoruz. ekonomik teşvikler (diğer adıyla kriptoekonomik) yoluyla bu tür davranışların uygulanmasına yardımcı olmak teşvikler. Bu teşvikler iki kategoriye ayrılır: açık ve örtülü, gerçekleşen sırasıyla staking ve gelecekteki ücret fırsatı (FFO) aracılığıyla. Bahis: Chainlink'de stake etme, diğer blockchain sistemlerinde olduğu gibi, ağ katılımcılarını, yani oracle düğümlerini, LINK token'ler biçiminde kilitli fonlar yatırmayı içerir. Bunlar Hisse ya da açık hisse dediğimiz fonlar açık bir teşviktir. onlar Düğüm arızası veya suiistimal durumunda hak kaybına tabidir. blockchain bağlamında, bu prosedüre genellikle eğik çizgi denir. Bununla birlikte, Chainlink içindeki oracle düğümleri tarafından stake etme, staking'dan temel olarak farklıdır. validators tarafından izinsiz blockchains'de. Doğrulayıcılar, işlemleri şüpheli hale getirerek veya ters yönde sipariş vererek yanlış davranabilirler. Temel fikir birliği protokolü 15Kullanıcılar bellek havuzundaki işlemleri değiştirebildiğinden, çıkarılan ve DON-gönderilen işlemler arasında doğru eşleşmenin sağlanmasına dikkat edilmelidir.Ancak izinsiz blockchain, validators'nin geçersiz bloklar oluşturmasını önlemek için katı ve hızlı blok doğrulama kuralları ve şifreleme temelleri kullanır. Buna karşılık, programatik korumalar hile yapan bir oracle ağının oluşturulmasını engelleyemez geçersiz raporlar. Bunun nedeni, iki sistem türü arasındaki temel farktır: blockchains'deki işlem doğrulaması bir iç tutarlılık özelliğidir, doğruluk ise bir iç tutarlılık özelliğidir. blockchain üzerindeki oracle raporların yüzdesi harici, yani zincir dışı verilerin bir özelliğidir. Chainlink ağ tabanlı için bir ön staking mekanizması tasarladık oracle düğümleri arasında harici verilerden yararlanabilen etkileşimli bir protokol üzerinde. Bu Mekanizma, açık ödüller kullanarak doğru davranış için mali teşvikler yaratır ve cezalar (kesme). Mekanizma ekonomik olduğundan düğüm oluşumunu önleyecek şekilde tasarlanmıştır. finansal kaynakları kullanarak düğümleri yozlaştırmak için kullanan bir düşmanın yolsuzluğu rüşvet. (Böyle bir düşman çok geneldir ve örneğin işbirliği yapan düğümlere kadar uzanır. kolektif kötü davranışlarından değer elde edin.) Tasarladığımız Chainlink staking mekanizması bazı güçlü ve yeni özelliklere sahiptir. özellikler.16 Bu tür ana özellik süper doğrusal staking etkidir (özellikle ikinci dereceden). Bir düşmanın, düğümlere yatırılan fonlardan önemli ölçüde daha fazla kaynağa sahip olması gerekir. Mekanizmayı yıkmak için. staking mekanizmamız ayrıca daha önce benzer sistemlerde düşünülenden daha güçlü bir rakibe karşı koruma sağlar: Düğümlerin gelecekteki davranışlarına göre rüşvet koşullandırması oluşturabilen bir düşman. Ayrıca DECO gibi Chainlink araçlarının staking'yi güçlendirmeye nasıl yardımcı olabileceğini tartışıyoruz. Hatalı düğüm davranışı durumunda doğru karar verilmesini kolaylaştıran mekanizma. Gelecekteki ücret fırsatı (FFO): Her iki PoW'un da izinsiz blockchain'leri ve PoS çeşitliliği — bugün örtülü teşvikler dediğimiz şeye eleştirel bir şekilde güveniyoruz. Bunlar Açık ödüllerden değil, dürüst davranışlara yönelik ekonomik teşvikler platform katılımının kendisinden. Örneğin, Bitcoin madenci topluluğu, güveni zedeleme riski nedeniyle %51 saldırısı düzenlemeye karşı teşvik ediliyor Bitcoin, değerini düşürüyor ve sonuç olarak kolektif değerleri aşındırıyor madencilik altyapısına yapılan sermaye yatırımları [150]. Chainlink ağı, bahsettiğimiz benzer bir örtülü teşvikten yararlanıyor gelecekteki ücret fırsatı (FFO) olarak. Güçlü performans geçmişlerine sahip Oracle düğümleri veya itibar kullanıcılardan ücret alır. oracle düğümünün yanlış davranışı geleceği tehlikeye atıyor ücret ödemeleri yapar ve böylece düğümü potansiyel açısından bir fırsat maliyetiyle cezalandırır. Ağa katılım yoluyla elde edilen gelir. Açık hisseye benzetme yaparak, FFO, örtülü bir menfaat biçimi, dürüst davranışa yönelik bir teşvik olarak görülebilir. bulunduğu platforma olan güveni sürdürmenin ortak faydasından kaynaklanmaktadır. Düğüm operatörlerinin işi, yani, düğümün olumlu performansına ve itibarına bağlıdır. ağ. Bu teşvik Chainlink ağının doğasında vardır ancak açıkça ifade edilmez protokoller. Bitcoin'de, yukarıda belirtildiği gibi madencilik faaliyetlerinin değerinin korunması 16Burada tanımladığımız staking mekanizması şu anda yalnızca doğru raporların teslim edilmesini sağlamayı amaçlamaktadır oracle ağları tarafından. Gelecekteki çalışmalarda birçok uygulamanın doğru şekilde yürütülmesini sağlamak için kapsamın genişletilmesini bekliyoruz. DONs diğer işlevleri sağlayacaktır.benzer şekilde örtülü bir pay biçimi olarak görülebilir. FFO'nun Chainlink içinde zaten mevcut olduğunu ve ağın güvenliğinin sağlanmasına yardımcı olduğunu vurguluyoruz bugün. Chainlink'nın daha da geliştirilmesine yönelik temel katkımız, FFO gibi örtülü teşviklerin değerlendirilmesine yönelik ilkeli, deneysel olarak yönlendirilen bir yaklaşım olacaktır. Örtülü Teşvik Çerçevesi (IIF) adını verdiğimiz şey. gibi miktarları tahmin etmek Düğümlerin gelecekteki ücret fırsatından yararlanan IIF, sürekli olarak kapsamlı Chainlink ağı tarafından toplanan performans ve ödeme verileri. Bu tür tahminler düğüm teşviklerini yansıtan staking sistemlerinin IIF tabanlı parametrelendirilmesine olanak tanıyacak mevcut buluşsal ve/veya statik modellerden daha yüksek doğrulukla. Özetlemek gerekirse, doğru oracle düğümüne yönelik iki ana ekonomik teşvik Gelişmekte olan Chainlink ağındaki davranış şöyle olacaktır: • Staking (yatırılan hisse) o Açık teşvik • Gelecekteki ücret fırsatı (FFO) o Örtülü teşvik Bu iki teşvik şekli birbirini tamamlayıcı niteliktedir. Oracle düğümleri aynı anda Chainlink staking protokolüne katılın, sürekli gelir akışından yararlanın kullanıcılar ve onların sürekli iyi davranışlarından toplu olarak faydalanırlar. Böylece her iki teşvik oracle ağı tarafından sağlanan kriptoekonomik güvenliğe katkıda bulunun. Ek olarak, iki teşvik birbirini güçlendirebilir ve/veya takas edebilir. Örneğin, performans geçmişi ve gelir akışı olmayan yeni bir oracle operatörü, dürüst davranışın garantisi olarak büyük miktarda LINK, böylece kullanıcıların ilgisini çeker ve ücretler. Bunun tersine, uzun ve nispeten hatasız bir hizmet ömrüne sahip yerleşik bir oracle operatörü performans geçmişi, geniş bir kullanıcı tabanından önemli ücretler talep edebilir ve bu nedenle örtülü bir teşvik biçimi olarak FFO'suna daha çok ağırlık veriyor. Genel olarak, burada ele aldığımız yaklaşım belirli miktarda oracle-network'ü hedefler rasyonel amaçlar için Chainlink'da mümkün olan en büyük ekonomik teşvikleri yaratacak kaynak aracıların (yani finansal faydalarını maksimuma çıkaran düğümlerin) dürüst davranmasını sağlar. Başka bir tane koy Bu şekilde amaç, bir düşmanın saldırması için gereken mali kaynakları en üst düzeye çıkarmaktır. ağ başarıyla. Matematiksel olarak iyi bir staking protokolü formüle ederek tanımlanmış ekonomik güvenliği ve aynı zamanda IIF'yi kullanarak, ekonomik güvenliğin gücünü ölçmeyi amaçlıyoruz. Chainlink'nin teşviklerini mümkün olduğunca doğru bir şekilde belirtin. Güvenilen sözleşmelerin yaratıcıları daha sonra bir oracle ağının uyumlu olup olmadığını güçlü bir güvenle belirleyebiliriz gerekli kriptoekonomik güvenlik seviyeleri. Ekonomik güvenliğin verimli döngüsü: Bu bölümde tartıştığımız teşvikler, staking ve FFO, güvenliği güçlendirmenin ötesinde bir etkiye sahiptir. DONs. Ekonomik güvenliğin verimli döngüsü dediğimiz şeyi başlatmayı vaat ediyorlar. Süper doğrusal staking etkisi (ve diğer ölçek ekonomileri), operasyonel performansın düşmesine neden olur DON'nin güvenliği arttıkça maliyet artar. Düşük maliyet, ek kullanıcıları DON'ye çeker,ücret ödemelerini artırmak. Ücret ödemelerindeki artış büyümeyi teşvik etmeye devam ediyor erdemli döngüyü sürdüren ağ. Ekonomik güvenliğin verimli döngüsünün sadece bir örnek olduğuna inanıyoruz. ölçek ekonomisi ve ağ etkisi bu bölümün ilerleyen kısımlarında tartışacağımız diğer konulardır. Bölüm organizasyonu: Staking, aşağıdakiler için kayda değer teknik ve kavramsal zorluklar sunar: yeni özelliklere sahip bir mekanizma tasarladık. Bu nedenle stake etme bu bölümdeki asıl odak noktamız. Bu belgede tanıttığımız staking yaklaşımına ilişkin genel bir bakışı Bölüm 9.1'de veriyoruz ve ardından Bölüm 9.2 ila 9.5'te ayrıntılı bir tartışma sunuyoruz. IFF'yi sunuyoruz Bölüm 9.6'da. Chainlink ağ teşviklerinin özet görünümünü Bölüm 9.7'de sunuyoruz. Bölüm 9.8'de, önerdiğimiz staking yaklaşımımızın oracle ağlarına getirebileceği verimli ekonomik güvenlik döngüsünü tartışıyoruz. Son olarak diğer potansiyelleri kısaca tanımlıyoruz. Bölüm 9.9'daki Chainlink ağının büyümesini hızlandırır. 9.1 Staking'e Genel Bakış Burada tanıttığımız staking mekanizma tasarımı, yukarıda belirtildiği gibi, oracle düğümleri arasında etkileşimli bir protokol içerir ve Dış verilerin raporlanması. Staking, rasyonel oracle düğümlerinden dürüst davranış sağlamayı amaçlamaktadır. Bu nedenle staking protokolüne saldıran bir düşmanı şu şekilde modelleyebiliriz: rüşvetçi: Düşmanın stratejisi mali teşvikler kullanarak oracle düğümlerini bozmaktır. Düşman, finansal kaynakları başarılı bir şekilde kurcalayarak ileriye dönük olarak elde edebilir. oracle raporuyla; örneğin elde edilen karı bozuk düğümlerle paylaşma teklifinde bulunun. staking mekanizma tasarımımızda aynı anda iki iddialı hedefi hedefliyoruz: 1. Güçlü bir rakibe direnmek: staking mekanizması koruma sağlamak için tasarlanmıştır oracle ağları karmaşık, geniş bir düşman sınıfına karşı kullanabilirsiniz. rüşvet teklif eden muhtemel rüşvet dahil olmak üzere koşullu rüşvet stratejileri Kimlikleri olaydan sonra belirlenen oracle'lara (ör. rüşvet teklif edenlere) oracles yüksek öncelikli uyarı için rastgele seçilmiştir). Diğer oracle tasarımları ise gerçekçi bir sistemin tüm yeteneklerine sahip olmayan dar bir dizi saldırıyı değerlendirdik Bildiğimiz kadarıyla, tanıttığımız düşman mekanizması Burada geniş bir rüşvet stratejileri dizisine açık bir şekilde değinen ve Bu modelde direnç. Modelimiz saldırganın dışındaki düğümlerin ekonomik olarak rasyoneldir (dürüst olmanın aksine) ve biz bir Tipik kullanım için aşırı derecede pahalı olan ancak mevcut olan gerçeğin kaynağı anlaşmazlık durumunda (aşağıda daha ayrıntılı olarak ele alınmıştır). 2. Süper doğrusal staking etkisine ulaşmak: Amacımız, rasyonel temsilcilerin raporlarından oluşan bir oracle ağının olmasını sağlamaktır. süper doğrusal bir bütçeye sahip bir saldırganın varlığında bile dürüstçetüm ağın yatırdığı toplam hisse miktarı. Mevcut staking sistemlerde, eğer n düğümden her biri $d tutarında hisse alırsa, bir saldırgan güvenilir bir rüşvet verebilir. düğümlerin biraz daha fazla bir ödeme karşılığında dürüst olmayan davranışlar sergilediğini \(d to each node, using a total budget of about \)dn. Bu zaten yüksek bir çıta Saldırganın toplam mevduat miktarına göre likit bir bütçesi olması gerekir. ağdaki tüm stakerlar. Amacımız daha da güçlü bir ekonomik güvenliktir zaten önemli olan bu engelden daha fazlası. İlk staking sistemini tasarlamayı hedefliyoruz Bu, n'de süper doğrusal bir bütçeyle genel bir saldırganın güvenliğini sağlayabilir. Aşağıda tartıştığımız gibi, pratik hususlar daha düşük bir etkiye sahip olsa da, ön tasarımımız, rakiplerden daha büyük bir bütçe gereksinimi sağlıyor $dn2/2, yani n cinsinden ikinci dereceden ölçeklendirme, rüşveti büyük ölçüde kullanışsız hale getiriyor düğümler yalnızca orta miktarda bahis oynadığında. Bu iki hedefe ulaşmak, teşvik tasarımının yenilikçi bir kombinasyonunu gerektirir ve kriptografi. Anahtar fikirler: staking yaklaşımımız, bekçi önceliği dediğimiz bir fikre dayanıyor. Chainlink oracle ağı tarafından oluşturulan ve bağlı bir sözleşmeye gönderilen bir rapor (örneğin bir varlık fiyatına ilişkin) katılımcı düğümlerin (örneğin medyan alınarak) katkıda bulunduğu bireysel raporlardan toplanır. Genellikle bir hizmet düzeyi sözleşmesi (SLA) raporlar için kabul edilebilir sapma sınırlarını, yani bir düğümün raporunun ne kadar ileri gidebileceğini belirtir. toplu rapordan sapma ve toplamın ne kadar değişmesine izin verilmesi gerektiği Doğru kabul edilecek gerçek değerden sapma. staking sistemimizde, belirli bir raporlama turu için her oracle düğümü şu şekilde hareket edebilir: toplu raporun yanlış olduğuna inanması durumunda bir uyarı verecek bir gözlemci. Her birinde raporlama turunda, her oracle düğümüne, uyarısının (varsa) işleneceği sıra. Mekanizmamız ödüllendirmeyi hedefliyor konsantrasyon, yani alarm verecek en yüksek öncelikli bekçi köpeği, Arızalı düğümlerin mevduatlarına el konularak elde edilen ödülün tamamı. staking sistem tasarımlarımız iki katman içerir: birincisi, varsayılan katman ve ikincisi, geri döndürmez katman. İlk katman, n düğümden oluşan bir dizi olan oracle ağının kendisidir. (Basitlik açısından, n'nin tek olduğunu varsayıyoruz.) Düğümlerin çoğunluğu yanlış değerler bildirirse, İlk kademenin alarm verme konusunda güçlü bir teşviki var. Bir uyarı verilmesi durumunda raporlama Ağın kararı daha sonra ikinci aşamaya aktarılır; bu, ağ hizmet düzeyi anlaşmasında kullanıcı tarafından belirlenebilen yüksek maliyetli, maksimum güvenilirlikli bir sistemdir. Bu, örneğin yalnızca güçlü düğümlerden oluşan bir sistem olabilir. tarihsel güvenilirlik puanları veya oracles'den daha büyük bir büyüklük sırasına sahip olan puanlar ilk katman. Ek olarak Bölüm 9.4.3'te tartışıldığı gibi DECO veya Town Crier hizmet verebilir ikinci kademede etkili ve kesin karar verilmesine yardımcı olacak güçlü araçlardır. Basitlik açısından bu ikinci kademe sistemin doğru bir rapora ulaştığını varsayıyoruz. değer. Tüm raporları oluşturmak için yalnızca ikinci aşamaya güvenmek çekici görünse de, Tasarımımızın faydası, sürekli olarak güvenlik özelliklerini sağlamasıdır.ikinci kademe sistem, tipik durumda yalnızca işletme maliyetini öderken birinci kademe sistemi. Watchdog önceliği aşağıdaki şekilde süper doğrusal staking etkisine neden olur: birinci kademe oracle ağı, yanlış sonuç ve bir dizi izleme düğümü çıkışı sağlıyor uyarısı, staking teşvik mekanizması en yüksek öncelikli gözlemciyi şu şekilde ödüllendirir: (Çoğunluktaki) yaramazlık yapan düğümlerin mevduatlarından dn/2 dolardan fazla para çekildi. Böylece toplam ödül bu tek bekçi köpeğinin elinde yoğunlaşmıştır. Bir düşmanın potansiyel bir bekçi köpeğine söz vermesi gereken minimum tutarı belirler onu uyarmamaya teşvik edin. Mekanizmamız her oracle öğesinin almasını sağladığından daha yüksek öncelikli gözlemcilerin rüşvetlerini kabul etmesi durumunda bekçi köpeği olarak hareket etme şansı (ve alarm vermemeyi seçmişse), düşman bu nedenle Herhangi bir uyarının verilmesini önlemek için her düğüme $dn/2. N düğüm olduğundan, Başarılı bir rüşvet için düşmanın gerekli bütçesi dn2/2 dolardan fazladır; ağdaki düğümlerin sayısı bakımından ikinci derecedendir. 9.2 Arka plan staking yaklaşımımız oyun teorisi ve mekanizması alanlarındaki araştırmalara dayanmaktadır tasarım (MD) (kitap referansı için bkz. [177]). Oyun teorisi matematiksel olarak Stratejik etkileşimin resmileştirilmiş çalışması. Bu bağlamda oyun böyle bir modeldir. Genellikle gerçek dünyada, mevcut eylem dizilerini kodlayan bir etkileşim Oyuna katılanlar, oyuncu olarak bilinirler. Bir oyun aynı zamanda elde edilen getirileri de belirtir bireysel oyuncular tarafından - oyuncunun seçtiği eylemlere ve diğer oyuncuların eylemleri. Belki de oyun içinde incelenen bir oyunun en bilinen örneği teori Mahkumların İkilemi [178]'dir. Oyun teorisyenleri genellikle anlamaya çalışırlar. Belirli bir oyunda temsil edilen denge veya dengeler (varsa). Bir denge hiçbir oyuncunun daha yüksek bir puan elde edemeyeceği şekilde bir dizi strateji (her oyuncu için bir tane) stratejisinden tek taraflı olarak saparak karşılığını alır. Bu arada mekanizma tasarımı, teşvikleri öyle tasarlama bilimidir ki Bir etkileşimin (ve onunla ilişkili oyunun) dengesi arzu edilen bazı özelliklere sahiptir. MD, oyun teorisinin tersi olarak görülebilir: Oyundaki kanonik soru Teori şu: "Teşvikler ve model göz önüne alındığında denge ne olacak?" MD'de, Bunun yerine soru şu: "Hangi teşvikler arzu edilen bir dengeye sahip bir oyunla sonuçlanacak?" Bir mekanizma tasarımcısının tipik hedefi 'teşvikle uyumlu' bir mekanizma oluşturmaktır; bu, mekanizmadaki katılımcıların (örneğin bir açık artırma veya diğer bilgiler) ortaya çıkarma sistemi [228]) bazı konularda gerçeği bildirmeye teşvik edilir (ör. belirli bir öğeye ne kadar değer veriyorlarsa). Vickrey (ikinci fiyat) müzayedesi belki de Katılımcıların kapalı teklif sundukları en iyi bilinen teşvik uyumlu mekanizma Bir ürün için en yüksek teklifi veren ürünü kazanır ancak ikinci en yüksek fiyatı öder [214]. Kriptoekonomi, kriptografiden yararlanan, alana özgü bir MD biçimidir Merkezi olmayan sistemlerde arzu edilen dengeyi yaratma teknikleri. Rüşvet ve gizli anlaşma tıp alanında önemli zorluklar yaratmaktadır. Yan sözleşmeler olarak tanımlanan gizli anlaşma durumunda hemen hemen tüm mekanizmalar bozulur.bir mekanizmaya katılan taraflar arasında [125, 130]. Dışarıdan bir tarafın oyuna yeni teşvikler kattığı rüşvet, daha da zorlu bir sorun teşkil ediyor gizli anlaşmadan daha iyidir; gizli anlaşma, oyunlar arasında özel bir rüşvet durumu olarak görülebilir. katılımcılar. Blockchain sistemleri genellikle parasal (kripto para birimine dayalı) getirisi olan oyunlar olarak kavramsallaştırılabilir. Basit bir örnek, İş Kanıtı madenciliğidir: madencilerin bir eylem alanı vardır blok kazmak için kullanılacak hashoranını seçebilecekleri. Madenciliğin getirisi, garantili bir negatif ödül (elektrik ve ekipman maliyeti) artı stokastik bir getiridir. diğer aktif madencilerin sayısına bağlı olan pozitif ödül (madencilik sübvansiyonu) [106, 172] ve işlem ücretleri. SchellingCoin [68] gibi kitle kaynaklı oracle'ler başka bir örnektir: eylem alanı bir oracle'nin gönderebileceği olası raporlar kümesidir. ödeme, oracle mekanizması tarafından belirlenen ödüldür; örneğin, ödeme şunlara bağlı olabilir: oracle raporunun diğer raporların medyanına ne kadar yakın olduğu hakkında [26, 68, 119, 185]. Blockchain oyunları, gizli anlaşma ve rüşvet saldırıları için olgun fırsatlar sunuyor; gerçekten, smart contracts bu tür saldırıları bile kolaylaştırabilir [96, 165]. Belki de en bilineni Kitle kaynaklı oracles'ye yönelik rüşvet saldırısı, p-plus-epsilon saldırısı [67]'dır. Bu saldırı oyuncuların boole değeri olan raporlar (yani yanlış veya doğru) gönderdiği ve kabul etmeleri halinde p ile ödüllendirildiği SchellingCoin benzeri bir mekanizma bağlamında ortaya çıkar. çoğunluk sunumu. Bir p artı epsilon saldırısında, saldırgan inandırıcı bir şekilde şunu vaat eder: örneğin, yalnızca çoğunluğun sunulması durumunda yanlış oyu vermeleri için kullanıcılara $p + ϵ ödeme yapın. Sonuç, tüm oyuncuların yanlış bildirimde bulunmaya teşvik edildiği bir dengedir. diğer oyuncuların ne yaptığından bağımsız olarak; sonuç olarak, rüşvetçi düğümleri harekete geçirebilir rüşveti ödemeden yalan beyanda bulunarak vaat edilen rüşvet aracılığıyla(!). Bununla birlikte, oracle'ler ve özellikle de kitle kaynaklı olmayan oracle'ler bağlamında diğer rüşvet stratejilerinin araştırılması, oldukça zayıf rakiplerle sınırlı kaldı modeller. Örneğin, PoW ortamında araştırmacılar sonuca bağlı olarak çalıştılar. rüşvet, yani yalnızca hedef mesajın başarıyla sansürlenmesi ve sansürlenmemesi durumunda ödenen rüşvetler bireysel madencinin eylemine bakılmaksızın bir blokta görünür [96, 165]. durumda oracles'nin sayısı, ancak p-plus-epsilon saldırısı dışında, yalnızca rüşvet verenin belirli bir şarta bağlı olarak rüşvet gönderdiği, kesinlikle sınırlı bir rüşvet modeli. sonuçta ortaya çıkan sonuç değil, bireysel oyuncunun eylemi. Burada teşvik edici olmaya devam eden bilgi ortaya çıkarma mekanizmalarının tasarımlarını çiziyoruz Bir sonraki alt bölümde açıklandığı gibi güçlü bir rakip modelde bile uyumludur. 9.3 Modelleme Varsayımları Bu alt bölümde oyuncuların davranış ve yeteneklerini nasıl modellediğimizi açıklıyoruz. sistemimiz, özellikle birinci kademe oracle düğümleri, ikinci kademedeki düğümler (karar) katman ve düşmanlar.9.3.1 Birinci Kademe Teşvik Modeli: Rasyonel Aktörler Pek çok blockchain sistem, güvenliğe bazı dürüst varsayımlara güvenir. katılan düğümler Düğümler protokolü takip etseler bile dürüst olarak tanımlanırlar. bunu yapmak onların mali çıkarlarına uygun olmadığında. İş Kanıtı sistemleri genellikle dürüst olmak için hash gücün çoğunluğunu gerektirir, Hisse Kanıtı sistemleri genellikle dürüst olmak için tüm katılan hisselerin 2/3'ünü veya daha fazlasını gerektirir ve hatta katman 2 sistemleri bile Arbitrum [141] en az tek bir dürüst katılımcı gerektirir. staking mekanizmamız için modelleme yaparken çok daha zayıf bir varsayımda bulunuyoruz. (Olmak açık, daha zayıf varsayımlar daha güçlü güvenlik özellikleri anlamına gelir ve bu nedenle tercih edilir.) Düşmanın bazı (azınlık) kontrolleri bozduğunu varsayıyoruz. birinci kademe oracle düğümlerin kesri. Geriye kalan düğümleri dürüst aracılar olarak değil, modelliyoruz. ancak rasyonel beklenen fayda maksimize ediciler olarak. Bu düğümler tamamen kişisel çıkarlara dayalı finansal teşviklere göre hareket eder ve beklenen finansal getiriyle sonuçlanan eylemleri seçerler. kazanç. Örneğin, bir düğüme, bunun sonucunda elde edilen ödülden daha büyük bir rüşvet teklif edilirse dürüst davranış, rüşveti kabul edecektir. Rakip düğümlere ilişkin not: Ortak güven modellemesine uygun olarak Merkezi olmayan sistemlerde, tüm düğümlerin rasyonel olduğunu, yani maksimize etmeye çalıştıklarını varsayıyoruz. kötü niyetli bir düşman tarafından kontrol edilmek yerine net gelir. Ancak iddialarımız... özellikle süper doğrusal veya ikinci dereceden staking darbe - asimptotik olarak sağlanmış durumda tutun bazı pozitif durumlar için, çekişmeli olarak kontrol edilen düğümler kümesinin en fazla (1/2 −c)n olduğu sabit c. 9.3.2 İkinci Kademe Karar Verme Modeli: Varsayıma Göre Doğruluk staking mekanizmamızın güvenliği sağlamaya yardımcı olan kritik bir özelliğinin olduğunu hatırlayın rasyonel düğümlere karşı ikinci kademe sistemidir. Önerilen staking mekanizmamızda, herhangi bir oracle şunu belirten bir uyarı verebilir: mekanizmanın çıktısının yanlış olduğuna inanıyor. Bir uyarı yüksek güven ile sonuçlanır İkinci kademe sistemin etkinleştirilmesi ve doğru sonucun bildirilmesi. Böylece önemli bir modelleme Yaklaşımımızın şartı doğru karar vermek, yani yargıç tarafından doğru raporlama yapmaktır. ikinci kademe sistemi. staking modelimiz, bozulmaz, maksimum düzeyde güvenilir bir doğruluk kaynağı olarak hareket eden ikinci kademe bir sistemi varsayar. Böyle bir sistemin pahalı ve yavaş olması muhtemeldir ve dolayısıyla tipik durum için kullanıma uygun değildir. Ancak denge durumunda, yani ne zaman birinci kademe sistem düzgün çalıştığında ikinci kademe sistem başlatılmayacaktır. Bunun yerine varlığı, bir güvenlik sağlayarak tüm oracle sisteminin güvenliğini artırır. yüksek güvenceli geri döndürmez kilit. Yüksek güvene sahip, yüksek maliyetli bir yargılama katmanının kullanılması temyiz sürecine benzer çoğu yargı sisteminin merkezinde yer alır. Ayrıca oracle tasarımında da zaten yaygındır. sistemler, örneğin, [119, 185]. İkinci aşamanın gerçekleştirilmesine yönelik yaklaşımları kısaca tartışıyoruz Bölüm 9.4.3'teki mekanizmamızda.staking protokolümüz, oracle düğümleri tarafından doğru raporlamayı zorunlu kılmak için ikinci kademe sistemin varsayılan doğru kararını güvenilir bir tehdit olarak kullanır. Protokol tarafından tanımlanan raporları üreten oracle düğümlerinin hisselerinin bir kısmına veya tamamına el koyar ikinci kademe sistemi yanlış olarak nitelendirdi. Oracle düğümleri böylece hatalı davranışlardan caydırılır bunun sonucunda ortaya çıkan mali ceza ile. Bu yaklaşım tat olarak kullanılana benzer. iyimser rollups, örneğin, [141, 10]. 9.3.3 Çekişmeli Model staking mekanizmamız, geniş ve iyi tanımlanmış bir düşman sınıfına karşı güvenliği sağlarken doğru bilgileri ortaya çıkarmak için tasarlanmıştır. Önceki çalışmalara göre iyileşir, ya açık bir rakip modeli göz ardı eder ya da dar rakip alt sınıflarına odaklanır, örneğin yukarıda tartışılan p-artı-epsilon rakibi. Amacımız bir staking tasarlamak olası tüm düşmanlara karşı resmi olarak kanıtlanmış güvenliği olan mekanizma pratikte karşılaşılacak. Düşmanımızı sabit (parametrelendirilebilir) bir bütçeye sahip olarak modelliyoruz. B $. Düşman, her oracle ile ayrı ayrı ve gizli olarak iletişim kurabilir. ve herhangi bir kişiye gizlice oracle garantili rüşvet ödemesi teklif edebilir mekanizmanın kamuya açık olarak gözlemlenebilir sonuçlarına bağlıdır. Sonuçların belirlenmesi Rüşvetler, örneğin oracle tarafından bildirilen değeri, herhangi bir genel mesajı içerebilir. herhangi bir oracle tarafından mekanizmaya gönderilir (ör. bir uyarı), diğer kişiler tarafından rapor edilen değerler oracles ve mekanizma tarafından çıkan değer. Sınırsız yeteneklere sahip bir saldırgana karşı hiçbir mekanizma güvenlik sağlayamaz. Bu nedenle bazı davranışların gerçekçi olmadığını veya kapsam dışı olduğunu düşünüyoruz. Saldırganımızı varsayıyoruz standart kriptografik temelleri kıramaz ve yukarıda belirtildiği gibi sabit bir (eğer potansiyel olarak büyük) bütçe $B. Ayrıca düşmanın kontrol etmediğini varsayıyoruz. oracle ağındaki iletişim, özellikle de önemli ölçüde geciktirilemez birinci kademe ve/veya ikinci kademe düğümler arasındaki trafik. (Düşmanın bu tür bir iletişimi gözlemleyip gözlemleyemeyeceği, aşağıda açıklayacağımız gibi, belirli mekanizmaya bağlıdır.) Ancak yukarıda belirtildiği gibi gayri resmi olarak, düşmanın şunları yapabileceğini varsayıyoruz: (1) Yolsuzluk oracle düğümlerin bir kesri ((1/2 −c)-bir sabit c için kesir), yani tam kontrol ve (2) Garantili ödeme koşuluyla istenen düğümlere rüşvet teklif etmek yukarıda açıklandığı gibi, düşman tarafından belirlenen sonuçlara göre. Rakibin tam olarak resmi bir modelini veya tam bir sınıflandırmasını sunmasak da Bu teknik incelemede çeşitli rüşvet verme yeteneklerine ilişkin örnekler yer almaktadır. rüşvetçiler modelimizin kapsamına giriyor. Basitlik açısından, oracles'nin Boolean yaydığını varsayıyoruz doğru değeri (w.l.o.g.) doğru olan ve nihai sonucun şu şekilde hesaplandığı raporlar tüketen bir smart contract tarafından kullanılacak bu raporların toplamı. Rüşvet verenin amaç nihai sonucun yanlış yani yanlış olmasıdır. • Koşulsuz rüşvet: Rüşvet veren, yanlış rapor veren herhangi bir oracle'ye $b rüşvet teklif eder. • Olasılıklı rüşvet: Rüşvet veren, herhangi bir oracle'ye q olasılığıyla $b rüşvet teklif ediyor bu yanlış rapor veriyor.• yanlış sonuç koşullu rüşvetçi: Rüşvet veren, nihai sonucun yanlış olması koşuluyla yanlış rapor veren herhangi bir oracle'ye b $ rüşvet teklif eder. • Uyarısız rüşvet veren: Rüşvet veren, rapor veren herhangi bir oracle'ya b $ rüşvet teklif eder Hiçbir uyarı verilmediği sürece yanlıştır. • p-plus-epsilon Rüşvet Veren: Rüşvet veren, yanlış olarak rapor veren herhangi bir oracle'ye b $ rüşvet teklif ediyor oracle'lerin çoğunluğu yanlış bildirmediği sürece. • Muhtemel rüşvetçi: Rüşvet veren, oracle seçilen kişiye önceden $b tutarında rüşvet teklif eder rastgele bir rol için ve yanlış rapor ediyor. Önerilen staking protokolümüzde, tümü düğümler potansiyel gözlemciler olarak hareket eder ve rastgeleleştirmenin Gözlemci önceliklerinin belirlenmesi olası rüşvete uygun değildir. Pek çok iş kanıtı, proof-of-stake ve izin verilen sistemler olası saldırılara karşı hassastır Ancak rüşvet, bu da onu düşmanlığımızda dikkate almanın önemini gösteriyor. modeli ve staking protokollerimizin buna dayanıklı olmasını sağlamak. Ek E'ye bakın daha fazla ayrıntı için. 9.3.4 Ne Kadar Kriptoekonomik Güvenlik Yeterli? Rasyonel bir düşman, bir sisteme saldırmak için yalnızca kar elde edebiliyorsa para harcar harcamalarından daha büyüktür. Bu nedenle rakip modelimiz ve önerilen staking için Mekanizmada B $, bir rakibin elde edebileceği potansiyel kârın bir ölçüsü olarak görülebilir. oracle ağını bozarak ve buna neden olarak smart contracts'ye güvenmekten kurtulmak için Yanlış bir rapor veya rapor dizisi oluşturmak için. Bir oracle ağının olup olmadığına karar verirken amaçları doğrultusunda yeterli düzeyde kriptoekonomik güvenlik sunduğundan, kullanıcının Ağı bu açıdan değerlendirin. Pratik ortamlarda makul rakipler için, genellikle $B'nin olmasını bekliyoruz. smart contracts'ye dayalı olarak toplam varlıklardan önemli ölçüde daha küçük. Çoğu durumda, Bir düşmanın bu varlıkları bütünüyle ele geçirmesi mümkün değildir. 9.4 Staking Mekanizması: Eskiz Burada staking mekanizmasının ana fikirlerini ve genel yapısını sunuyoruz. şu anda düşünüyorlar. Sunum kolaylığı için basit ama yavaş bir tarif anlatacağız. (çok turlu) protokol bu alt bölümde yer almaktadır. Ancak bu planın oldukça uygun olduğunu belirtelim. pratik. Mekanizmanın sağladığı ekonomik güvenceler, yani hatalı düğümlerin cezalandırılması ve buna bağlı teşvikler göz önüne alındığında, birçok kullanıcı bunu yapmaya istekli olabilir. Raporları iyimser bir şekilde kabul edin. Başka bir deyişle, bu tür kullanıcılar önceden raporları kabul edebilirler. ikinci aşama tarafından potansiyel karar. Raporları iyimser bir şekilde kabul etmek istemeyen kullanıcılar, protokol tamamlanana kadar beklemeyi seçebilirler. yürütme, yani ikinci aşamaya herhangi bir potansiyel yükselme gerçekleşene kadar sona erer. Bu, ancak raporların onay süresini önemli ölçüde yavaşlatabilir. Bu nedenle kısacaŞekil 15: Uyarı içeren staking şemasının şeması. Bu örnekte 1⃝ çoğunluk Düğümlerin oranı bozuk / rüşvet alıyor ve doğru değer yerine yanlış bir ˜r değeri yayıyor rapor değeri r. Gözlemci düğümü 2⃝ikinci kademe komiteye bir uyarı gönderir, hangi 3⃝doğru rapor değeri r'yi belirler ve yayar, bu da düğümlerin bozulmasına neden olur mevduatlarını kaybederler - her biri gözlemci düğümü 4⃝'ye d $. biraz daha fazla ise daha hızlı (tek turlu) sonuç veren bazı optimizasyonların ana hatlarını çizin Bölüm 9.5'teki karmaşık tasarım. staking mekanizmamızdaki ilk katmanın temel oracle'den oluştuğunu hatırlayın. ağın kendisi. Yukarıda açıklandığı gibi mekanizmamızın ana yapısı her turda, Her düğüm belirli bir önceliğe sahip bir “bekçi köpeği” olarak hareket edebilir ve bu nedenle Mekanizma doğru bir çıktı yerine yanlış bir çıktıya ulaşırsa bir uyarı verir. bir r. Bu uyarı, doğru sonuca ulaştığını varsaydığımız ikinci aşama çözümlemeye neden olur. rapor et. Yanlış rapor veren düğümler cezalandırılır, yani bahisleri kesildi ve bekçi köpeklerine verildi. Bu temel yapı oracle sistemlerinde yaygındır, örneğin [119, 185]'te olduğu gibi. Yukarıda kısaca bahsettiğimiz tasarımımızdaki en önemli yenilik, her düğümün potansiyel gözlemcilerin sıralanmasında ayrı bir öncelik verilmiştir. Yani bekçiler öncelik sırasına göre uyarma fırsatları verilir. Bir düğümün aşağıdaki özelliklere sahip olması durumunda şunu hatırlayın: Uyarı vermek için en yüksek önceliğe sahiptir; her hatalı davranışın kesilen $d depozitosunu alır düğümü, toplamda \(dn/2 = \)d × n/2'den fazla, çünkü hatalı bir rapor, Kötü düğümlerin çoğunluğu. Sonuç olarak, düşmanın en azından bu ödülü ödemesi gerekir. keyfi bir düğüme rüşvet vermek. Bu nedenle, düğümlerin çoğuna rüşvet vermek için düşmanın bir miktar ödeme yapması gerekir. Düğümlerin çoğuna büyük miktarda rüşvet, yani kesinlikle $dn2/2'den fazla. Şekil 15'te uyarı ve gözlemci yükseltmenin nasıl çalıştığını şematik olarak gösteriyoruz.9.4.1 Diğer Mekanizma Detayları Şimdi daha ayrıntılı olarak açıkladığımız rüşvete karşı koruma sistemi, basitleştirilmiş bir taslaktır. inşa etmeyi planladığımız iki katmanlı yapı. Odak noktamızın çoğu açıklama üzerinde olacak birinci kademe ağ (bundan sonra bağlamdan açıkça anlaşıldığı yerde sadece “ağ” olarak anılacaktır) boyunca teşvik mekanizması ve ikinci kademeye yükselme prosedürü ile. Sorumlu olan n oracle düğümden oluşan bir Chainlink ağı düşünün. düzenli olarak (örneğin, dakikada bir) bir boolean değeri raporlayarak (örneğin, pazarın BTC'nin kapitalizasyonu ETH'ninkini aşıyor). staking mekanizmasının bir parçası olarak düğümler iki depozito sağlamalıdır: anlaşmazlık durumunda kesintiye tabi olan $d tutarında bir depozito çoğunluk ve gözlemci depozitosu $dw ile birlikte, arıza durumunda kesinti yapılabilir tırmanma. Düğümlerin diğer düğümlerin gönderimlerini kopyalayamayacağını varsayıyoruz; Bölüm 5.3'te tartışıldığı gibi bir taahhüt-açıklama şeması aracılığıyla. Her turda ilk önce düğümler raporlarını taahhüt edin ve tüm düğümler taahhütte bulunduktan (veya zaman aşımı süresi dolduğunda) düğümler raporlarını açıklar. Oluşturulacak her rapor için, her düğüme ayrıca 1 ile n arasında rastgele seçilen ve 1'in en yüksek önceliğe sahip olduğu bir gözlemci önceliği verilir. Bu öncelik şunları sağlar: ödülün tek bir bekçi köpeğinin elinde toplanması. Tüm raporlar kamuya açıklandıktan sonra, bir uyarı aşaması başlar. Bir n (senkron) tur dizisi boyunca, düğüm öncelik i, i. turda uyarı yapma fırsatına sahiptir. Düğümler ortaya çıktıktan sonra mekanizmanın olası sonuçlarını ele alalım. onların raporları. Yine bir ikili rapor varsayalım, doğru değerin doğru olduğunu ve yanlış olan yanlıştır. Ayrıca, birinci kademe mekanizmanın şu çıktıyı verdiğini varsayalım: Nihai rapor olarak düğümler tarafından çoğunluk değeri çıktısı r. Mekanizmada üç olası sonuç vardır: • Tam anlaşma: En iyi durumda, düğümler tam bir anlaşma içindedir: tüm düğümler Mevcuttur ve aynı r değerine (doğru ya da doğru) ilişkin zamanında bir rapor sunmuşlardır. veya yanlış). Bu durumda, ağın yalnızca r'yi bağlı sözleşmelere iletmesi gerekir ve her düğümü tur başına sabit bir $p ödemesiyle ödüllendirin; bu çok daha küçüktür d dolardan fazla. • Kısmi anlaşma: Bazı düğümlerin çevrimdışı olması veya hangi değerin doğru olduğu konusunda anlaşmazlık olması mümkündür, ancak çoğu düğüm doğru rapor verir ve yalnızca Azınlık raporları yanlış. Bu dava aynı zamanda basittir. Çoğunluk değeri (doğru) hesaplanır ve doğru bir rapor elde edilir r. R bildiren tüm düğümler $p ile ödüllendirilirken, hatalı rapor veren oracle'lerin depozitoları var Mütevazı bir kesinti yapıldı, örneğin 10 peni. • Uyarı: Bir gözlemcinin ağ çıkışının hatalı olduğuna inanması durumunda, mekanizmayı ikinci kademe ağa ileterek halka açık bir uyarıyı tetikler. O halde iki olası sonuç vardır: – Doğru uyarı: İkinci düzey ağ, çıktının doğrulandığını doğrularsaŞekil 16: Yoğunlaştırılmış uyarı ödülleri yoluyla rüşvetçinin maliyetinin artırılması. Rüşvet Düşman, her düğüme, uyarı vererek kazanacağı ödülden daha fazlasını rüşvet vermelidir (kırmızı çubukla gösterilir). Uyarıcı ödüller paylaşılıyorsa bu ödül göreceli olarak daha yüksek olabilir. küçük. Yoğunlaştırılmış uyarı ödülleri, herhangi bir düğümün alabileceği ödülü artırır (uzun kırmızı çubuk) elde edin. Sonuç olarak, geçerli bir rüşvet için karşı tarafın ödediği toplam tutar (gri bölgeler), paylaşılan uyarı ödüllerinden ziyade konsantre olarak çok daha büyüktür. birinci kademe ağ hatalıydı, uyarı veren gözlemci düğümü bir ödül alıyor tüm kesintili mevduatlardan oluşuyor ve dolayısıyla $dn/2'den fazla. – Arızalı uyarı: İkinci kademe ve birinci kademe oracle'ler aynı fikirdeyse, üst kademeye iletme işlemi şu şekilde yapılır: hatalı kabul edilir ve uyarıyı veren düğüm $dw mevduatını kaybeder. Raporların iyimser bir şekilde kabul edilmesi durumunda, gözlemci uyarıları dayanak sözleşmelerin uygulanmasında herhangi bir değişiklik. Beklemek üzere tasarlanan sözleşmeler için ikinci kademe komite tarafından olası tahkim, gözlemci uyarıları gecikiyor ancak Sözleşmenin yürütülmesini dondurmayın. Sözleşmelerde ayrıca bir atama yapılması da mümkündür. karar verme dönemleri için yük devretme DON. 9.4.2 İkinci Dereceden Staking Etkisi Her düğümün, katı düğüm önceliğiyle birleştirilmiş bir gözlemci görevi görme yeteneği ödüllerin yoğunlaşmasını sağlayarak mekanizmanın ikinci dereceden staking elde etmesini sağlar Bölüm 9.3.3'te açıklanan her tür rüşvet veren saldırgan için etki. Bunu hatırlayın Bu, özellikle bizim ortamımızda, her biri depozitolu n düğümlü bir ağ için şu anlama gelir: Başarılı bir rüşvetçinin (yukarıdaki türlerden herhangi biri) $d tutarından daha büyük bir bütçesi olmalıdır. $dn2/2. Daha kesin olmak gerekirse, rüşvet verenin en az (n+1)/2 düğümü bozması gerekir, çünkü rüşvet verenin n düğümün çoğunluğunu bozar (tek n için, varsayıma göre). Böylece bir bekçi köpeği ayakta durur $d(n + 1)/2 tutarında bir ödül kazanın. Sonuç olarak rüşvet veren bu tutarı herkese ödemek zorundadır.Hiçbir düğümün bekçi köpeği gibi davranmamasını sağlamak için. Resmi olarak şunu göstermek için çalışıyoruz: rüşvet verenin bütçesi en fazla $d(n2 + n)/2 ise alt oyun mükemmel dengesi rüşvet verenler ve oracle'ler arasındaki oyunun, diğer bir deyişle dengenin Oyunun oynanması sırasında herhangi bir noktada rüşvet verenin rüşveti vermemesi ve her biri oracle gerçek değerlerini dürüstçe bildirmelidir. Başarılı bir rüşvetçinin nasıl bir sertifikaya ihtiyaç duyabileceğini yukarıda açıkladık. bütçesi, düğüm mevduatlarının toplamından önemli ölçüde daha büyük. Bunu göstermek için Sezgisel sonuç, Şekil 16, yoğunlaştırılmış uyarı ödüllerinin etkisini grafiksel olarak göstermektedir. Orada gördüğümüz gibi, eğer bekçi köpeğini uyarmanın ödülü, yani rüşvet verilen mevduatlar ise yanlış bildiren düğümler)—tüm potansiyel uyarılar arasında bölünmüştür; Uyarı veren herhangi bir düğümün bekleyebileceği, nispeten küçük olması $d. Rüşvetçi, d dolardan daha büyük bir ödemenin olası olmadığını bilerek, n düğümün her birine birden fazla rüşvet vermek için yanlış sonuçlu koşullu rüşvet $d + ϵ. Sezgilerin tersine, Şekil 16, ödülü geniş çapta dağıtan bir sistemin olduğunu göstermektedir. Uyarı sinyali veren düğümler arasında ödülün yoğunlaştığı düğümlerden çok daha zayıftır. tek bir bekçi köpeğinin elleri. Örnek parametreler: Her biri n = 100 düğümden oluşan (birinci kademe) bir ağ düşünün \(d = \)20K yatırılıyor. Bu ağa yatırılan toplam 2 milyon dolar olacaktır ancak \(100M = \)dn2/2 bütçeli rüşvete karşı korunun. Sayısını arttırmak oracles elbette $d'yi artırmaktan daha etkilidir ve dramatik bir etkiye sahip olabilir: n = 300 düğüme ve \(d = \)20K depoya sahip bir ağ, bir 900 milyon dolara kadar bütçesi olan rüşvetçi. Bir staking sisteminin çoğu durumda temsil eden smart contract'leri koruyabileceğini unutmayın. sunulan rüşvet koruma seviyesinden daha fazla değer. Bunun nedeni bir düşmanın Bu sözleşmelere saldırmak çoğu durumda tam değeri elde edemez. Örneğin, bir Chainlink-destekli 1 Milyar Dolar değerindeki sözleşme yalnızca bir kişiye karşı teminat gerektirebilir kaynağı 100 milyon dolar olan rüşvetçi çünkü böyle bir düşman makul bir şekilde kar elde edebilir sözleşme bedelinin yalnızca %10'u kadardır. Not: Bir ağın değerinin ikinci dereceden büyüyebileceği fikri şu şekilde ifade edilir: bir ağın değerinin şöyle olduğunu belirten iyi bilinen Metcalfe Yasası [167, 235] bağlı varlıkların sayısı ikinci dereceden artar. Ancak Metcalfe Yasası teşvikimizde ikinci dereceden staking etkisinden farklı bir olgu olan potansiyel ikili ağ bağlantılarının sayısındaki artıştan kaynaklanmaktadır. mekanizma. 9.4.3 İkinci Aşamanın Gerçekleştirilmesi İki operasyonel özellik, yüksek güvenilirliğe sahip ikinci katmanın gerçekleştirilmesini kolaylaştırır: (1) İkinci kademe karar verme, oracle ağlarında nadir görülen bir olay olmalıdır ve bu nedenle birinci kademenin normal işletiminden önemli ölçüde daha maliyetli olacaktır ve (2) Varsayalımiyimser bir şekilde kabul edilen raporlar veya icrası tahkimi bekleyebilecek sözleşmeler ikinci katmanın gerçek zamanlı olarak yürütülmesine gerek yoktur. Bu özellikler bir dizi sonuç verir belirli DONs gereksinimlerini karşılamak için ikinci katmana yönelik yapılandırma seçenekleri. Örnek bir yaklaşım olarak, ikinci kademe bir komite, bir kişi tarafından seçilen düğümlerden oluşabilir. DON (yani birinci katman), Chainlink'deki en uzun süre hizmet veren ve en güvenilir düğümlerden ağ. Önemli ilgili operasyonel deneyime ek olarak, operatörler Bu tür düğümlerin FFO'da bir arzuyu motive eden önemli ölçüde örtülü bir teşviki vardır. Chainlink ağının son derece güvenilir kalmasını sağlamak için. Ayrıca kamuya açık olarak güvenilirliklerine şeffaflık sağlayan mevcut performans geçmişleri. İkinci kademe düğümlerin, birinci kademe ağın katılımcıları olmalarına gerek olmadığını belirtmekte fayda var ve birden fazla birinci kademe ağdaki arızaları tespit edebilir. Belirli bir DON içindeki düğümler, böyle bir n′ kümesini önceden belirleyebilir ve kamuya açık olarak taahhüt edebilir DON için ikinci kademe komiteyi oluşturan düğümler. Ayrıca, DON düğümler, ikinci kademe oyların sayısını belirleyen bir k′ ≤n′ parametresi yayınlar birinci kademe düğümü cezalandırmak için gereklidir. Belirli bir rapor için bir uyarı oluşturulduğunda, ikinci kademenin üyeleri, her biri tarafından sağlanan değerlerin doğruluğu konusunda oy kullanır. Birinci kademe düğümlerden. k' olumsuz oyu alan herhangi bir birinci kademe düğümü, kendi hakkını kaybeder. gözlemci düğümüne yatırılır. Yargılamanın nadir olması ve uzun süreli infaz fırsatı nedeniyle Yukarıda belirtildiği gibi, birinci kademenin aksine, ikinci kademedeki düğümler şunları yapabilir: 1. Karar verme karşılığında yüksek ücret alın. 2. İlkinin kullandığı çeşitli kümelerin bile ötesinde ek veri kaynaklarından yararlanın. 3. Örneğin tespit etmek ve belirlemek için manuel ve/veya uzman incelemesine ve müdahalesine güvenin. Kaynak verilerdeki hataları uzlaştırın ve dürüst bir düğüm aktarımı arasında ayrım yapın hatalı veriler ve hatalı davranan bir düğüm. İkinci kademe düğümlerin seçimi ve politikayı belirleyen kararların seçimi için az önce tanımladığımız yaklaşımın, geniş bir aralıkta sadece bir noktayı temsil ettiğini vurguluyoruz. ikinci kademenin olası gerçekleştirilmelerinin tasarım alanı. Teşvik mekanizmamız şunları sunuyor: ikinci aşamanın nasıl gerçekleştirileceği konusunda tam esneklik. Bireysel DON'ler böylece belirli gereksinimleri karşılayan ikinci kademeleri için kurallar oluşturur ve belirler ve katılımcı düğümlerin ve kullanıcıların beklentileri. Karar verme aracı olarak DECO ve Town Crier: İkinci kademe için önemli mekanizmamızda rakip birinci kademe düğümler arasında ayrım yapabilmek için kasıtlı olarak yanlış raporlar ve kasıtsız olarak dürüst birinci kademe düğümler üretirler. kaynakta yanlış olan verileri aktarın. Ancak o zaman ikinci kademe uygulamaya geçebilir Mekanizmamızın amacı olan hile yapmayı caydırmak için kesmek. DECO ve Town Crier ikinci kademe düğümlerin bu kritik ayrımı yapmasını sağlayan güçlü araçlardır güvenilir bir şekilde.İkinci katman düğümleri bazı durumlarda kullanılan veri kaynağını doğrudan sorgulayabilir Birinci kademe düğüm tarafından veya yanlış bir rapor olup olmadığını kontrol etmek için ADO Bölüm 7.1'i kullanın. hatalı bir veri kaynağından kaynaklanmıştır. Ancak diğer durumlarda ikinci kademe düğümler eksik olabilir. birinci kademe düğümün veri kaynağına doğrudan erişim. Bu gibi durumlarda doğru karar verilmesi mümkün görünmüyor veya öznel yargıya güvenmeyi gerektiriyor. Önceki oracle Uyuşmazlık sistemleri, bu tür sorunları çözmek için verimsiz ve giderek artan oylama turlarına güvenmektedir. zorluklar. Ancak DECO veya Town Crier kullanarak birinci kademe düğüm doğru davranışı kanıtlayabilir ikinci kademe düğümlere. (İki sistemle ilgili ayrıntılar için Bölüm 3.6.2'ye bakın.) Özellikle, eğer ikinci kademe düğümü, birinci kademe düğümün hatalı bir rapor değeri ˜r ürettiğini tanımlar, birinci kademe düğüm, kurcalamaya dayanıklı kanıt oluşturmak için DECO veya Town Crier'ı kullanabilir. (TLS etkin) bir kaynaktan doğru şekilde aktardığı ikinci kademe düğümleri DON tarafından yetkili olarak tanındı. Kritik olarak, birinci kademe düğüm bunu yapabilir veri kaynağına doğrudan erişim gerektiren ikinci kademe düğümler olmadan.17 Sonuç olarak, İstenilen herhangi bir veri kaynağı için Chainlink'da doğru karar verilmesi mümkündür. 9.4.4 Yanlış Bildirme Sigortası staking mekanizmamız tarafından elde edilen güçlü rüşvet direnci, temel olarak Uyarıcılara verilen fonların kesilmesiyle ilgili. Parasal bir ödül olmasaydı, uyarıcılar rüşveti reddetmeye yönelik doğrudan bir teşvik yoktur. Ancak sonuç olarak kesintiye uğrayan fonlar Yanlış raporlardan zarar gören kullanıcılara (ör. para kaybeden kullanıcılara) tazminat ödenebilir smart contract numaralı telefona yanlış fiyat verileri aktarıldığında. Varsayıma göre hatalı raporlar, raporların bir yetkili makam tarafından kabul edilmesi durumunda sorun teşkil etmez. ancak potansiyel kararın ardından, yani ikinci kademenin eyleminden sonra sözleşme yapılabilir. Açıklandığı gibi Ancak yukarıda mümkün olan en iyi performansı elde etmek için sözleşmeler bunun yerine doğru raporlamayı zorunlu kılacak mekanizma konusunda iyimserler; bu da kabul ettikleri anlamına geliyor Potansiyel ikinci kademe karardan önce raporlar. Gerçekten de bu kadar iyimser bir davranış bütçeleri aşılmayan rasyonel rakipleri varsayarak modelimizde güvenlidir. staking mekanizmanın etkisi. Aşağıdakilerden kaynaklanan olası olmayan bir mekanizma arızası olayından endişe duyan kullanıcılar: Örneğin, çok büyük mali kaynaklara sahip olan rakipler, yanlış raporlama sigortası şeklinde ek bir ekonomik güvenlik katmanı kullanmak isteyebilirler. biliyoruz Halihazırda bu türden akıllı sözleşmeye dayalı politikalar sunmayı planlayan çok sayıda sigorta şirketi var DAOs gibi yenilikçi mekanizmalar da dahil olmak üzere yakın gelecekte Chainlink güvenli protokoller için, örneğin [7]. Chainlink için performans geçmişinin varlığı Düğümler ve pay miktarları gibi düğümlerle ilgili diğer veriler, aktüeryal risk değerlendirmeleri için olağanüstü güçlü bir temel sağlayarak politikaların fiyatlandırılmasını mümkün kılar. Poliçe sahipleri için ucuz, sigortacılar için ise sürdürülebilir yöntemlerle. 17Town Crier ile birinci kademe düğümlerin yerel olarak kanıt oluşturması da mümkündür Çıktıkları raporların doğruluğundan emin olmak ve bu doğrulamaları ikinci kademe düğümlere sağlamak gerektiği gibi temel.Yanlış raporlama sigortasının temel biçimleri güvenilir ve smart contracts kullanarak verimli bir şekilde. Basit bir örnek olarak parametrik sigorta Teşvik mekanizmamızın devreye girmesi durumunda sözleşme SCin'leri poliçe sahiplerine otomatik olarak tazminat ödeyebilir. ikinci katman, birinci katmanda oluşturulan bir rapordaki hatayı tanımlar. Bir sigorta poliçesi satın almak isteyen bir kullanıcı U, örneğin bir hedefin yaratıcısı SC sözleşmesi, merkezi olmayan bir sigortacıya poliçe tutarı için talepte bulunabilir Sözleşmede $M. U'nun onaylanması üzerine sigortacı, devam eden (örneğin aylık) bir ücret belirleyebilir. SCin cinsinden $P primi. U primi ödediği sürece poliçesi aktif kalır. SC'de bir raporlama hatası meydana gelirse sonuç bir çiftin (r1, r2) emisyonu olacaktır. r1'in mekanizmamızdaki ilk kademe tarafından imzalandığı SC için çelişen raporların sayısı ve İlgili düzeltilmiş rapor olan r2, ikinci kademe tarafından imzalanır. Eğer U sağlarsa Böyle geçerli bir çiftin (r1, r2) SCins'e verilmesi durumunda, sözleşme ona otomatik olarak M $ ödeyecektir; prim ödemeleri günceldir. 9.5 Tek Yuvarlak Varyant Önceki alt bölümde açıklanan protokol, ikinci kademe komitenin, bir gözlemcinin alarm verip vermediğini belirlemek için n tur beklemesini gerektirir. Bu Bu gereklilik, iyimser durumda, yani ilk kademenin çalıştığı durumda bile geçerlidir. doğru. Raporları iyimser bir şekilde, yani potansiyel bir gelişmeden önce kabul etmek istemeyen kullanıcılar için karar verme durumunda, bu yaklaşımla ilgili gecikme işe yaramaz olacaktır. Bu nedenle, yalnızca bir tane gerektiren alternatif protokolleri de araştırıyoruz. yuvarlak. Bu yaklaşımda, tüm oracle düğümleri, alarm vermek istiyorlar. İkinci kademe komite daha sonra bu değerleri kontrol eder. öncelik sırası. Kaba bir taslak sağlamak için böyle bir şema aşağıdakileri içerebilir: adımlar: 1. Watchdog bit gönderimi: Her düğüm Oi sırrı, bir bitlik watchdog değerini paylaşır Ürettiği her rapor için ikinci katmandaki düğümler arasında wi ∈{uyarı yok, uyarı}. 2. Anonim ipuçları: Herhangi bir oracle düğümü, gözlemci bitlerinin gönderildiği aynı turda ikinci kademe komiteye anonim bir ipucu α gönderebilir. Bu ipucu α Mevcut rapor için bir uyarının verildiğini belirten bir mesajdır. 3. Watchdog bit kontrolü: İkinci kademe komitesi oracle düğümlerin watchdog'unu ortaya çıkarır bitler öncelik sırasına göre Düğümlerin uyarı vermedikleri zaman hiçbir uyarı izleme biti göndermemeleri gerektiğini unutmayın: aksi takdirde, trafik analizi tüm düğümlerin bitlerini ortaya çıkarır. Protokol uyarı yok durumunu ortaya koyuyor En yüksek öncelikli uyarı gözlemcisinden daha yüksek önceliğe sahip düğümlerin gözlemci bitleri. Ortaya çıkan şeyin n-yuvarlak protokolümüzle aynı olduğunu gözlemleyin. Ödüller de bu şemaya göre, yani ilk tanımlanan bekçi köpeğiyle aynı şekilde dağıtılır. Yanlış raporlar gönderen düğümlerin kesilmiş mevduatlarını alır.İsimsiz ipuçlarının kullanılması, ikinci kademe komitenin herhangi bir uyarının yapılmadığı durumlarda etkileşimsiz kalmasını sağlayarak iletişim karmaşıklığını azaltır. ortak durumda. Uyarıda bulunan herhangi bir gözlemcinin, isimsiz bir ihbarda bulunma konusunda ekonomik bir teşviki olduğunu unutmayın: Eğer herhangi bir ihbar gönderilmezse, herhangi bir kişiye ödül ödenmez. düğüm. İsimsiz bir ihbarın göndereni Oi'nin α tarafından tespit edilememesinin sağlanması Ağ verilerine dayalı olarak düşmana anonim ihbar, anonim bir adres üzerinden gönderilebilir. örneğin Tor aracılığıyla veya daha pratik olarak bir bulut hizmet sağlayıcısı aracılığıyla proxy aracılığıyla. Kime Ucun O'dan kaynaklandığını doğrulamak için Oi, bir halka imzası kullanarak α'yı imzalayabilir [39, 192]. Alternatif olarak, ikinci kademe komiteye kötü niyetli bir oracle düğümü tarafından yapılan atıf yapılamayan hizmet reddi saldırılarını önlemek için α, anonim bir kimlik bilgisi olabilir. geri alınabilir anonimlik [73]. Bu protokol, pratik olarak ulaşılabilir olmakla birlikte, biraz ağır bir mühendisliğe sahiptir. gereksinimleri (ki bunları azaltmanın yollarını araştırıyoruz). Örneğin birinci kademe düğümler, bir dizinin bakımını gerektiren ikinci kademe düğümlerle doğrudan iletişim kurmalıdır. Anonim kanallara ve halka imzalara duyulan ihtiyaç mühendisliğe katkıda bulunur planın karmaşıklığı. Son olarak, kısaca tartışılan özel bir güven gereksinimi vardır. aşağıdaki notta. Bu nedenle, hâlâ başarıya ulaşan daha basit programları da araştırıyoruz. süper doğrusal staking etki, ancak ikinci dereceden daha az olabilir; örneğin, rüşvet verenin asimptotik olarak en az $n log n değerinde kaynağa ihtiyacı vardır. kapsamındaki bazı şemalar Göz önünde bulundurulması gereken nokta, gözlemci görevi görecek katı bir düğüm alt kümesinin rastgele seçilmesidir. bu durumda olası rüşvet özellikle güçlü bir saldırı haline gelir. Açıklama: Bu tek turlu staking mekanizmasının güvenliği, erişilemezlik gerektirir oracle ile ikinci kademe düğümler arasındaki kanallar; zorlamaya dirençli sistemlerde standart bir gereklilik, örneğin oylama [82, 138] ve pratikte makul bir gerekliliktir. Ancak buna ek olarak, rüşvet verenle işbirliği yapmayı amaçlayan bir Oi düğümü, rüşvet verene belirli bir şifreyi kodladığını gösterecek şekilde gizli paylaşımları değer. Örneğin, Oi rüşvet verenin hangi düğümleri kontrol ettiğini bilmiyorsa, o zaman Oi şunları yapabilir: 0 değerli hisseleri tüm komite üyelerine iletin. Rüşvet veren kişi daha sonra Oi'nin bilgilerini doğrulayabilir olasılıksal olarak uyum. Herhangi bir tek turlu protokolde bu sorunu önlemek için, Oi'nin en az bir dürüst ikinci kademe düğümün kimliğini bilmesini gerektirir. Her ikinci kademe düğümün bir rastgeleleştirme eklediği etkileşimli bir protokolle Rüşvetçinin yapabileceği en iyi şey Oi tarafından rastgele bir seçim yapılmasını zorunlu kılmaktır. bekçi köpeği biti. 9.6 Örtülü Teşvik Çerçevesi (IIF) FFO, Chainlink ağında doğru davranış için örtülü bir teşvik biçimidir. o Ekonomik güvenliğin sağlanmasına yardımcı olması bakımından açık hisse, yani mevduat gibi işlevlere sahiptir. ağ. Başka bir deyişle, FFO (etkili) depozitonun bir parçası olarak dahil edilmelidir. Ağdaki bir düğümün $d'si.Soru şu: FFO'yu ve diğer örtülü teşvik biçimlerini nasıl ölçeriz? Chainlink ağı içinde mi? Örtülü Teşvik Çerçevesi (IIF), bir dizi bu amaçla geliştirmeyi planladığımız ilke ve teknikler. Blockchain sistemleri benzeri görülmemiş şeffaflığın birçok biçimini ve düğümün yüksek güvenilirliğe sahip kayıtlarını sağlar yarattıkları performans, IIF'nin nasıl çalışacağına dair vizyonumuz için bir sıçrama tahtasıdır. Burada IIF'nin temel unsurlarına ilişkin fikirleri kısaca özetliyoruz. IIF'nin kendisi, değerlendirmede önemli olduğunu belirlediğimiz bir dizi faktörden oluşacaktır. örtülü teşviklerin yanı sıra ilgili verilerin analitik algoritmalar tarafından tüketilmek üzere yüksek güvenceli bir biçimde yayınlanmasına yönelik mekanizmalar. Farklı Chainlink kullanıcılar IIF'yi farklı şekillerde kullanmak istiyorsanız, örneğin farklı faktörlere farklı ağırlıklar vererek. Kullanıcıların IIF'yi uygulamalarına yardımcı olacak analitik hizmetlerinin toplulukta ortaya çıkmasını bekliyoruz. bireysel risk değerlendirme tercihlerine göre ve amacımız Bu hizmetleri yüksek güvenceli ve zamanında destekleyici verilere erişimlerini sağlayarak, aşağıda tartıştığımız gibi (Bölüm 9.6.4). 9.6.1 Gelecek Ücret Fırsatı Düğümler, ağların bu belgede tanımladığımız çeşitli hizmetlerden herhangi biri için ödediği ücretlerden pay almak üzere Chainlink ekosistemine katılır: sıradan veriler, merkezi olmayan kimlik, adil sıralama gibi gelişmiş hizmetlere beslenir, ve gizliliği koruyan DeFi. Chainlink ağındaki ücretler, düğüm operatörlerinin örneğin sunucuları çalıştırma, gerekli veri lisanslarını edinme ve bakımını yapma maliyetlerini destekler Yüksek çalışma süresi sağlamak için küresel bir personel. FFO, giderler düşüldükten sonra hizmet ücretlerini ifade eder, Bir düğümün gelecekte kazanacağı veya hatalı davranış sergilemesi durumunda kaybedeceği anlamına gelir. FFO, ağın güvenliğini sağlamaya yardımcı olan bir hisse şeklidir. FFO'nun yararlı bir özelliği, zincir içi verilerin (zincir dışı verilerle desteklenen) gerçek olmasıdır. veri), bir düğümün geçmişine ilişkin yüksek güvenirliğe sahip bir kayıt oluşturarak FFO'nun hesaplanmasını sağlar şeffaf ve ampirik olarak yönlendirilmiş bir şekilde. FFO'nun basit, birinci dereceden bir ölçüsü, bir işletmenin ortalama net gelirinden elde edilebilir. düğümü belirli bir süre boyunca (yani brüt gelir eksi işletme giderleri) FFO olabilir daha sonra örneğin gelecekteki kümülatif net gelirin net bugünkü değeri [114] olarak hesaplanır, diğer bir deyişle, gelecekteki tüm kazançların zaman iskontolu değeri. Ancak düğüm geliri, örneğin Şekil 17'de gösterildiği gibi değişken olabilir. Daha da önemlisi, düğüm geliri sabit bir dağılım izlemeyebilir zamanla. Sonuç olarak, FFO'yu tahmin ederken araştırmayı planladığımız diğer faktörler şunları içerir: • Performans geçmişi: Bir operatörün performans geçmişi (raporlarının doğruluğu ve zamanlılığının yanı sıra çalışma süresi de dahil olmak üzere) bir hedef sağlar kullanıcıların güvenilirliğini değerlendirmeleri için mihenk taşı. Performans geçmişi böylece kullanıcıların oracle düğüm seçiminde (veya gelişiyle birlikte) kritik bir faktör sağlar DONs'nin seçimi, DONs'nin seçimi). Güçlü bir performans geçmişi muhtemelen devam eden yüksek gelirle ilişkilidir.18 18Ele almayı planladığımız önemli bir araştırma sorusu, sahte hizmet hacimlerinin tespitidir.Şekil 17: Chainlink düğümlerinin tek bir veri akışında (ETH-USD) kazandığı gelir Mart 2021'de temsili bir hafta. • Veri erişimi: oracles açık API'lerden birçok veri biçimi elde edebilirken, belirli veri biçimleri veya belirli yüksek kaliteli kaynaklar yalnızca belirli bir sitede mevcut olabilir. abonelik esasına göre veya sözleşmeye dayalı anlaşmalar yoluyla. Belirli kişilere ayrıcalıklı erişim veri kaynakları istikrarlı bir gelir akışı oluşturmada rol oynayabilir. • DON katılımı: DONs'nin gelişiyle düğüm toplulukları gelecek belirli hizmetleri sağlamak için birlikte çalışırlar. Birçok DON'in şunları içermesini bekliyoruz: saygın DONs'ye katılım sağlayarak seçici bir temelde operatörler Tutarlı bir gelir kaynağı sağlamaya yardımcı olan ayrıcalıklı pazar konumu. • Platformlar arası etkinlik: Bazı düğüm operatörleri, örneğin PoS validator'ler veya diğer bağlamlarda köklü varlık ve performans izleme kayıtlarına sahip olabilir. blockchain dışı bağlamlardaki veri sağlayıcıları. Bu diğer sistemlerdeki performansları (veri güvenilir bir biçimde mevcut olduğunda) değerlendirmeye bilgi verebilir performans geçmişlerini öğrenin. Benzer şekilde, Chainlink ağında hatalı davranış Kullanıcıları (örn. FFO) uzaklaştırarak bu diğer sistemlerdeki geliri tehlikeye atabilir platformlara yayılabilir. 9.6.2 Spekülatif FFO Düğüm operatörleri Chainlink ağına yalnızca gelir elde etmek için katılmaz operasyonları yürütmek için değil, işleri yürütmek için yeni fırsatlardan yararlanmak üzere kendilerini yaratmak ve konumlandırmaktır. Başka bir deyişle, ağdaki oracle düğümlerin harcamaları da DeFi ve diğer akıllı sözleşme uygulamalarının geleceği hakkında olumlu bir açıklama etki alanlarının yanı sıra oracle ağlarının blockchain olmayan yeni ortaya çıkan uygulamaları. Düğüm operatörleri bugün mevcut Chainlink ağlarında mevcut olan ücretleri aynı anda kazanıyor Bunlar, internet sitelerindeki sahte incelemelere genel olarak benzer; tek fark, sorunun sitede daha kolay olmasıdır. oracle ayarı çünkü malların, yani raporların sipariş edilip edilmediğine dair kesin bir kaydımız var ve teslim edilir - örneğin çevrimiçi mağazalardan sipariş edilen fiziksel ürünlerin aksine. Başka bir deyişle oracle Bu ayarda müşteri doğruluğu doğrulanamasa bile performans doğrulanabilir.konumlandıracak bir itibar, performans geçmişi ve operasyonel uzmanlık oluşturun avantajlı bir şekilde gelecekteki ağlarda mevcut olan ücretleri kazanmaları (tabii ki koşullu) dürüst davranış hakkında). Bugün Chainlink ekosisteminde faaliyet gösteren düğümler bu konuda sense ek ücret kazanma konusunda yeni gelenlere göre avantajlıdır Chainlink hizmetler kullanılabilir duruma gelir. Bu avantaj, yeni operatörlerin yanı sıra köklü bir üne sahip teknoloji şirketleri için de geçerlidir; örneğin, geleneksel bir T-Systems teknoloji sağlayıcısı (Deutsche Telekom'un yan kuruluşu) ve büyük bir merkezi şirket olan Kraken değişimi, Chainlink ekosisteminde ilk varlıkları oluşturmuştur [28, 143]. oracle düğümlerinin gelecekteki fırsatlara bu şekilde katılması başlı başına bir fırsat olarak değerlendirilebilir bir tür spekülatif FFO olarak kabul edilir ve dolayısıyla Chainlink'de bir tür hisse oluşturur ağ. 9.6.3 Dış İtibar IIF, tanımladığımız gibi, kesinlikle takma adlı bir ağda çalışabilir. operatörler, yani ilgili kişiler veya gerçek dünyadaki varlıklar açıklanmadan. Bununla birlikte, sağlayıcıların kullanıcı seçimi için potansiyel olarak önemli bir faktör dışsaldır. itibar. Dış itibarla, takma adlardan ziyade gerçek dünyadaki kimliklere ilişkin güvenilirlik algısını kastediyoruz. İtibar riskiyle bağlantılı gerçek dünyadaki kimlikler örtülü bir teşvik biçimi olarak görülebilir. İtibarı görüyoruz IIF'nin merceğinden, yani kriptoekonomik anlamda, bir kuruluş aracı olarak FFO tahminlerine dahil edilebilecek platformlar arası etkinlik. FFO tahminlerinde dış itibarın bir faktör olarak kullanılmasının faydası Takma adla bağlantıya bağlı olan şey, dış itibarın performansı yalnızca bir operatörün mevcut faaliyetlerinin yanı sıra gelecekteki faaliyetlerini de kapsar. Örneğin kötü bir şöhrete sahipseniz bir kişiye bağlanırsa, o kişinin gelecekteki girişimlerini lekeleyebilir. Başka bir deyişle, dış itibar, takma addan daha geniş bir FFO kapsamını yakalayabilir performans kayıtları, bir kişiye veya yerleşik bir suiistimalin etkisi olarak şirketten kaçmak, takma adlı bir operasyonla bağlantılı olandan daha zordur. Chainlink merkezi olmayan kimlik teknolojileriyle uyumludur (Bölüm 4.3) IIF'de dış itibarın kullanılması konusunda destek sağlayabilir. Bu tür teknolojiler Doğrulayabilir ve böylece operatörlerin iddia ettiği gerçek dünya bilgilerinin doğruluğunun sağlanmasına yardımcı olabilir kimlikler.19 9.6.4 IIF Analytics'i açın IIF, belirttiğimiz gibi, güvenilir açık kaynaklı veriler ve araçlar sağlamayı amaçlamaktadır. örtülü teşvik analitiği. Amaç, topluluk içindeki sağlayıcıları etkinleştirmektir. farklı bölümlerinin risk değerlendirme ihtiyaçlarına göre uyarlanmış analitikler geliştirmek Chainlink kullanıcı tabanı. 19Merkezi olmayan kimlik bilgileri, istendiğinde takma adları doğrulanmış bilgilerle de süsleyebilir. ek bilgi. Örneğin, bir düğüm operatörü prensipte bu tür kimlik bilgilerini aşağıdaki amaçlarla kullanabilir: hangisi olduğunu açıklamadan Fortune 500 şirketi olduğunu kanıtlayın.Düğümlerin geliri ve performansına ilişkin önemli miktarda geçmiş veri Yüksek güvene sahip, değişmez bir formda zincirde bulunur. Ancak amacımız, Yalnızca kapalı olarak görülebilen davranışlara ilişkin veriler de dahil olmak üzere mümkün olan en kapsamlı veriler Zincir Dışı Raporlama (OCR) veya DON etkinliği gibi zincir. Bu tür veriler potansiyel olarak hacimli olun. Onu saklamanın ve bütünlüğünü sağlamanın, yani onu tehlikelerden korumanın en iyi yolu kurcalamanın, tartışılan teknikleri kullanarak DONs yardımıyla olacağına inanıyoruz Bölüm 3.3'te. staking gibi bazı teşvikler doğrudan ölçüm biçimlerine uygundur. mevduat ve temel FFO. Spekülatif FFO ve itibar gibi diğerlerinin anlaşılması daha zordur. objektif bir şekilde ölçüyoruz ancak aşağıdakiler de dahil olmak üzere destekleyici veri biçimlerinin olduğuna inanıyoruz: Chainlink ekosisteminin tarihsel büyümesi, sosyal medya itibar ölçümleri vb., ölçülmesi daha zor olan bu öğeler için bile IIF analitik modellerini destekleyebilir. Özel DON'lerin özellikle izleme, doğrulama ve doğrulama için ortaya çıktığını hayal edebiliriz. Düğümlerin zincir dışı performans kayıtlarına ilişkin verilerin yanı sıra diğer verileri kaydedin IIF'de kullanılan, doğrulanmış kimlik bilgileri gibi. Bu DON'ler, Chainlink topluluğuna hizmet veren tüm analiz sağlayıcıları için tek tip, yüksek güvenliğe sahip IIF verileri sağlayabilir. Ayrıca analitik sağlayıcıların iddialarını yerine getiren altın bir kayıt da sağlayacaklar. topluluk tarafından bağımsız olarak doğrulanabilir. 9.7 Hepsini Bir Araya Getirmek: Düğüm Operatörü Teşvikleri Düğüm operatörleri için açık ve örtülü teşviklere ilişkin yukarıdaki tartışmalarımızın sentezi Düğüm operatörlerinin katılma ve bunlardan faydalanma yollarına bütünsel bir bakış sağlar Chainlink ağı. Kavramsal bir kılavuz olarak, söz konusu toplam varlıkları belirli bir Chainlink ile ifade edebiliriz. düğüm operatörü $S kabaca şu şekilde stilize edilmiştir: \(S ≈\)D + \(F + \)FS + $R, nerede: • $D, tüm ağlarda açıkça yatırılan tüm hisselerin toplamıdır. operatör katılır; • $F, tüm ağlardaki tüm FFO'ların toplamının net bugünkü değeridir. operatörün katıldığı; • $FS, operatörün spekülatif FFO'sunun net bugünkü değeridir; ve • $R, operatörün Chainlink ekosistemi dışındaki itibar eşitliğidir oracle düğümlerinde tanımlanan hatalı davranışlar nedeniyle tehlikeye girebilir. Büyük ölçüde kavramsal olsa da, bu kaba eşitlik, Chainlink düğümlerinin yüksek güvenilirlik performansını destekleyen çok sayıda ekonomik faktörün bulunduğunu yararlı bir şekilde göstermektedir. $D dışındaki tüm bu faktörler günümüzün Chainlink ağlarında mevcuttur.9.8 Ekonomik Güvenliğin Erdemli Döngüsü Süper doğrusal staking etkisinin ücret ödemelerinin temsiliyle birleşimi IIF'deki gelecekteki ücret fırsatı (FFO), erdemli döngü dediğimiz şeye yol açabileceğinden oracle ağında ekonomik güvenliğin sağlanması. Bu bir tür ekonomi olarak görülebilir ölçekli. Belirli bir ağ tarafından güvence altına alınan toplam tutar arttıkça, Sabit miktarda ekonomik güvenlik eklemek için gereken ek pay, azaldıkça azalır Kullanıcı başına ortalama maliyet. Bu nedenle, bir kullanıcının katılması ücretler açısından daha ucuzdur Ağ ekonomisinde aynı artışı elde etmek yerine halihazırda mevcut bir ağ yeni bir ağ oluşturarak güvenlik. Daha da önemlisi, her yeni kullanıcının eklenmesi, söz konusu ağın önceki tüm kullanıcıları için hizmetin maliyeti. Belirli bir ücret yapısı göz önüne alındığında (örneğin yatırılan miktara ilişkin belirli bir getiri oranı), bir ağ tarafından kazanılan toplam ücret artarsa, bu durum ek gelir akışını teşvik eder Daha yüksek bir oranda güvence altına almak için ağa yatırım yapın. Özellikle, eğer toplam bahis Sistemde tutulabilecek bireysel bir düğüm sınırlandırılır, ardından yeni ücret ödemeleri yapılır sisteme girin, FFO'sunu yükseltin, n düğüm sayısı artacaktır. sayesinde teşvik sistemi tasarımımızın süper doğrusal staking etkisi, ekonomik güvenliği sistem n'den daha hızlı yükselecektir; örneğin Bölüm 9.4'te çizdiğimiz mekanizmada n2 gibi. Sonuç olarak, ekonomik güvenliğin ortalama maliyeti, yani katkıda bulunan hisse miktarı bir dolarlık ekonomik güvenlik düşecek. Ağ bu nedenle kullanıcılarından ücret alabilir daha düşük ücretler. oracle hizmetlerine olan talebin esnek olduğunu varsayarsak (örneğin, kısa bir bilgi için bkz. [31]) açıklama), talep artacak ve ek ücretler ve FFO oluşturacaktır. Bu noktayı aşağıdaki örnekle açıklıyoruz. Örnek 5. Teşvikimizle oracle ağının ekonomik güvenliği sağlandığından plan \(dn2 for stake \)dn'dir, bir dolarlık hissenin sağladığı ekonomik güvenlik n'dir ve dolayısıyla ekonomik güvenliğin dolar başına ortalama maliyeti - yani hisse miktarı Bir dolarlık ekonomik güvenliğe katkı 1/n'dir. Ekonomik teşviklerin tamamen FFO'dan oluştuğu ve üst sınırının belirlendiği bir ağ düşünün düğüm başına \(d ≤\)10K. Ağın n = 3 düğüme sahip olduğunu varsayalım. Daha sonra ortalama maliyet Ekonomik güvenliğin doları başına yaklaşık 0,33 dolar. Ağın toplam FFO'sunun \(30K (e.g., to \)31K'nın üzerine çıktığını varsayalım. Verilen Düğüm başına FFO üst sınırı, ağ (en azından) n = 4'e kadar büyür. Şimdi ortalama maliyet Ekonomik güvenliğin doları başına yaklaşık 0,25 dolara düşüyor. Şekil 18'de oracle ağlarındaki ekonomik güvenliğin tam verimli döngüsünü şematik olarak gösteriyoruz. Ekonomik güvenliğin verimli döngüsünün bu etkiden kaynaklandığını vurguluyoruz. Kullanıcıların ücretlerini bir havuzda toplaması. Daha büyük şirketler lehine çalışan onların kolektif FFO'larıdır. ağ boyutları ve dolayısıyla daha fazla kolektif güvenlik. Ayrıca erdemli döngüye de dikkat çekiyoruz. Ekonomik güvenliğin arttırılması, DONs'nin finansal sürdürülebilirliğe ulaşması lehine çalışıyor. Bir kez oluşturulan, kullanıcı ihtiyaçlarını karşılayan DON'ler, şu noktaya kadar büyümelidir: ücretlerden elde edilen gelir, oracle düğümlerin işletim maliyetlerini aşıyor.

Şekil 18: Chainlink staking erdemli döngüsünün şeması. Kullanıcı ücretinde artış oracle ağına yapılan ödemeler 1⃝onun büyümesine neden olarak ekonomik büyümesine yol açar güvenlik 2⃝. Bu süper doğrusal büyüme, Chainlink ağlarında ölçek ekonomisi sağlıyor 3⃝. Özellikle, ekonomik güvenliğin ortalama maliyetinde bir azalma anlamına gelir; ücret ödemelerinden veya diğer hisse kaynaklarından kaynaklanan dolar başına ekonomik güvenlik artar. Kullanıcılara aktarılan düşük maliyetler, oracle talebinin artmasını teşvik ediyor hizmetler 4⃝. 9.9 Ağ Büyümesini Sağlayan Ek Faktörler Chainlink ekosistemi genişlemeye devam ettikçe çekiciliğinin de artacağına inanıyoruz kullanıcılar açısından ve altyapı olarak önemi blockchain ekonomisi için hızlanacak. oracle ağları tarafından sağlanan değer süper doğrusaldır, yani daha hızlı büyürağların boyutundan daha fazladır. Değerdeki bu büyüme her ikisinden de kaynaklanmaktadır. Ölçek ekonomisi (hizmet hacimleri arttıkça kullanıcı başına daha yüksek maliyet verimliliği) ve ağ etkileri—kullanıcılar DONs'yi daha geniş çapta benimsedikçe ağ faydasının artması. Mevcut smart contract'ler daha güvenli ve tamamen yeni değer görmeye devam ettikçe smart contract uygulamalar daha merkezi olmayan hizmetler sayesinde mümkün oluyor; DONs'ye ödenen ücretlerin kullanımı ve toplam ücretleri artmalı. Ücret havuzlarının arttırılması daha da merkezi olmayan hizmetler yaratmanın araçlarına ve teşviklerine dönüşecek, verimli bir döngüyle sonuçlanır. Bu verimli döngü kritik bir tavuk-yumurta sorununu çözüyor hibrit smart contract ekosistemindeki sorun: Yenilikçi smart contract özellikleri genellikle henüz mevcut olmayan merkezi olmayan hizmetler gerektirir (örneğin, sıklıkla yeni DeFi pazarlar) yeni veri beslemeleri gerektirir) ancak ortaya çıkabilmesi için yeterli ekonomik talebe ihtiyaç duyarlar. Mevcut DON'ler için çeşitli smart contract'ler tarafından ücretlerin bir havuzda toplanması, talebin sinyalini verecektir. Büyüyen bir kullanıcı tabanından gelen ek merkezi olmayan hizmetler, bunların yaratılmasına yol açıyor DONs tarafından ve yeni ve çeşitli hibrit smart contracts'nin sürekli etkinleştirilmesiyle. Özet olarak, ağ güvenliğindeki büyümenin erdemli yaklaşımlarla sağlandığına inanıyoruz. Chainlink staking mekanizmasındaki döngüler, daha büyük büyüme modellerini örneklendirir Chainlink ağı, merkezi olmayan şirketler için zincir üstü bir ekonominin ortaya çıkmasına yardımcı olabilir hizmetler.

Çözüm

Bu yazıda Chainlink'nin gelişimi için bir vizyon ortaya koyduk. Ana tema Bu vizyonda oracle ağlarının çok daha geniş bir hizmet yelpazesi sağlama yeteneği yer alıyor. Yalnızca veri dağıtımından smart contracts daha fazla. DONs'yi geleceğin merkezi olmayan hizmetleri için bir temel olarak kullanan Chainlink, yüksek performanslı, gizliliği geliştirilmiş oracle işlevselliği sağlamayı hedefleyecektir. oracle ağları güçlü bir güven minimizasyonu sunacak staking gibi ilkeli kriptoekonomik mekanizmaların bir kombinasyonu aracılığıyla ve dikkatle tasarlanmış korkuluklar ve ana zincirlere dayalı hizmet düzeyinde uygulama. DONs ayrıca katman 2 sistemlerinin işlemlerde esnek, adil sıralama politikaları uygulamasına ve ayrıca bellek havuzuna yönlendirilen işlemler için daha düşük gas maliyetlerine yardımcı olacaktır. Birlikte ele alındığında, bu yeteneklerin tümü güvenli ve zengin işlevselliğe sahip hibrit akıllı teknolojilere doğru ilerlemektedir. sözleşmeler. DONs'nin esnekliği mevcut Chainlink hizmetlerini geliştirecek ve birçok ek smart contract özellik ve uygulama. Bunlar arasında kesintisiz çok çeşitli zincir dışı sistemlere bağlantı, merkezi olmayan kimlik oluşturma Altyapı açısından kritik önem taşıyan hizmetlerin zamanında teslim edilmesine yardımcı olmak için mevcut veriler ve öncelikli kanallar işlemler ve gizliliği koruyan DeFi araçlar. Burada ortaya koyduğumuz vizyon iddialı. Kısa vadede güçlendirmeyi amaçlıyoruz. bugün smart contracts'nin ulaşamayacağı hedeflere ulaşmak için hibrit sözleşmeler uzun vadede merkezi olmayan bir meta katman gerçekleştirmeyi hedefliyoruz. Ne mutlu ki çizebiliriz fikir birliği algoritmalarından sıfır bilgi kanıtına kadar uzanan yeni araçlar ve fikirler üzerine Toplumun hızla gelişen araştırmaların meyvesi olarak geliştirdiği sistemler.

Benzer şekilde, yanıt olarak bu makaledeki fikirlerin uygulanmasına öncelik vermeyi bekliyoruz. Chainlink kullanıcı topluluğunun ihtiyaçlarına göre. Bir sonraki aşamayı sabırsızlıkla bekliyoruz smart contracts'yi evrensel bağlantı yoluyla güçlendirme ve Dünyanın yeni nesil finansal sisteminin omurgası olarak merkezi olmayan teknolojiler ve hukuk sistemleri. Teşekkür Bu makaledeki rakamları sundukları için Julian Alterini ve Shawn Lee'ye teşekkür ederiz.