Optimistic Execution: Uzlaşılamayan konularda uzlaşmak

Mona Lisa dünyanın en güzel tablosu mu? Bu blog yazısı şimdiye kadar yazılmış en iyi yazı mı? Bu sorular, her gün karşılaştığımız pek çok soru gibi özneldir. Bu tür konulardaki görüşler kişiden kişiye büyük ölçüde değişebilir ve bu da fikir birliğine varmayı zorlaştırır.

Blokzincirler bu öznelliği işleyemez, çünkü yalnızca deterministik denen işlemlerle çalışırlar. Öznel sorular ise deterministik değildir: Aynı girdi için bile farklı bir çıktı alabilirsiniz.

Öznellik ve deterministik olmama

Sıradan bir blokzincir, Mona Lisa'nın dünyanın en güzel tablosu olup olmadığını yanıtlayamaz. Web gibi sürekli değişen bir kaynaktan veri okumak gibi deterministik olmayan başka hiçbir senaryoyla da baş edemez. Bu işi yapmak için yeni türde bir blokzincire ihtiyacınız var!

GenLayer bu deterministik olmama sorununu çözebilir mi? Önce şuna bakalım: Bu “soruna” nasıl varıyoruz?
(Spoiler: Çözebilir)

İyimser yaklaşım: Verimlilik ile güvenilirlik arasında denge

Deterministik olmama sorununa, yani “öznel soruna”, GenLayer'ın bakış açısından bakalım ve şimdiye kadar bildiklerimizi hatırlayalım. GenLayer çok sayıda doğrulayıcıdan oluşur; her birinin bir miktar stake edilmiş GEN tokenı vardır ve her biri bir büyük dil modeline erişebilir.

GenLayer'da doğrulayıcılar arasındaki konsensüs mekanizması hakkında daha fazla bilgi edinin.

Lider ile doğrulayıcılar arasındaki etkileşim

GenLayer'ın işlem doğrulamaya yaklaşımı iyimserdir: Her doğrulayıcının her işlemi doğrulaması gerekmez. Varsayılan olarak her işlemi teyit etme görevi, rastgele seçilen beş doğrulayıcıdan oluşan bir gruba verilir. Ancak GenLayer'da sihirli değnek geliştiricilerin elindedir. Kendi projeleri için istedikleri asgari doğrulayıcı sayısını yükseltebilirler; böylece işlem maliyeti artar, ama daha güçlü güvenlik güvenceleri elde ederler.

Konsensüse varmak için doğrulayıcılardan oluşan küçük bir alt grup yeterli olduğundan bu iyimser yaklaşım işlemlerin verimli biçimde işlenmesini sağlar. Peki doğrulayıcılar deterministik olmayan işlemler üzerinde gerçekte nasıl mutabakata varabilir?

Deterministik olmama sorununu eşdeğerlikle çözmek

GenLayer'ın konsensüs mekanizmasının kalbinde Eşdeğerlik İlkesi yatar. Bu ilke, LLM tabanlı işlemlerin deterministik olmayan doğasıyla baş etmek için vazgeçilmezdir.

Girişteki öznel (ve deterministik olmayan) soruya dönelim: Mona Lisa dünyanın en güzel tablosu mu? Farklı LLM'lere sorulduğunda bu soru, her biri kendi gerekçesine sahip farklı yanıtlara yol açabilir.

• Evet, çünkü renkler kusursuz bir uyum içinde.
• Evet, çünkü Mona Lisa'nın gülüşü dünyanın en güzel gülüşü.
• Hayır, Van Gogh'un Yıldızlı Gece'si daha güzel.

Böyle bir durumda neyin eşit sayılacağını belirlemeden konsensüse nasıl varılır?

Her zaman olduğu gibi GenLayer'da kararı geliştiricilere bırakıyoruz: Eşdeğerlik İlkesi, kendi kullanım senaryoları için kabul edilebilir yanıtın ne olduğunu tanımlamalarını sağlar.

Eşdeğerliği simgeleyen terazi

Örneğin GenLayer üzerine kurulmuş, hasar taleplerini gerçek dünyadaki olaylara göre ödeyen bir parametrik sigorta platformu düşünün. Geliştirici, Eşdeğerlik İlkesi'ni şöyle ayarlayabilir: Farklı haber kaynaklarını tarayan doğrulayıcıların yanıtları, bir kasırganın yaşandığı konusunda hemfikirlerse eşdeğer sayılır. Bu durumda bir doğrulayıcının “Evet, bir kasırga var” yanıtı, başka bir doğrulayıcının “Evet, bir kasırga karaya çıkıyor.” yanıtıyla eşdeğer kabul edilebilir.

Bu küçük ama önemli bir fark. Belki de bildiğiniz gibi GenLayer üzerinde, bir felaketin gerçekleşmesine bağlı olarak poliçe sahiplerine ödeme yapan bir parametrik sigorta platformu kurabilirsiniz. Böyle bir platformda kasırganın karaya çıkıp çıkmadığı çok önemli bir ayrıntı olabilir.

GenLayer'da neyin eşdeğer sayıldığı hakkında daha fazla bilgi edinin.

Konsensüs mekanizması: Liderin önerisini doğrulamak

Ağa bir işlem gönderildiğinde seçilen doğrulayıcılardan biri lider olarak belirlenir. Lider işlemi yürütür ve bir çıktı önerir; diğer doğrulayıcılar da bu çıktıyı geliştiricinin belirlediği Eşdeğerlik İlkeleri'ne göre değerlendirir. Doğrulayıcı sayısı her zaman tek olduğundan, belirlenen Eşdeğerlik İlkesi çerçevesinde konsensüse varılması garantidir.

Her doğrulayıcı işlemi bağımsız olarak yürütür ve deterministik olmayan her çağrı için kendi çıktısını liderin önerileriyle karşılaştırır. Doğrulayıcıların çoğunluğu liderin çıktılarıyla hemfikirse işlem geçerli sayılır. Bu süreç sayesinde çıktılar birebir aynı olmasa da projenin gereksinimleri bağlamında eşdeğerdir.

İtiraz süreci: Konuyu Yüksek Mahkemeye taşımak

Doğrulayıcı sayısı her zaman tek olduğundan, konsensüs için rastgele kaç doğrulayıcı gerekirse gereksin işlem üzerinde genellikle mutabakata varılabilir. Yine de işlemlerin sonuçsuz kalma olasılığı var; bu konuyu başka bir blog yazısında ele alacağız.

İlk doğrulayıcı grubunun kararına katılmayan herkes, itiraz penceresi içinde itiraz talebinde bulunabilir. İtiraz penceresi, bir işlem gönderildikten sonra o işlem için itiraz talebinde bulunulabilen süredir. Her yeni itirazla itiraz penceresi yeniden başlar.

İtiraz süreci

Her itirazda işlemi daha büyük bir doğrulayıcı grubu yeniden değerlendirir. En az beş doğrulayıcının yer aldığı standart durumda doğrulayıcı grubu 11'e çıkarılır. Yeni bir lider seçilir ve lider olmayan doğrulayıcıların sayısı iki katına çıkar.

Bu süreç konsensüse varılana ya da tüm doğrulayıcılar sürece katılana kadar devam eder. Şunu da belirtelim: Yüksek güvenilirlik sağlamak isteyen bir kullanıcı gas maliyetini baştan ödeyebilir; böylece tüm doğrulayıcılar bu işlem üzerinde mutabakata varabilir. İtiraz süreci bir bütün olarak mahkeme sistemine benzetilebilir: Orada da son merciye, örneğin Yüksek Mahkemeye ulaşana kadar kararlara itiraz edilebilir. Anayasal hakları ihlal edilen bir kişi de doğrudan Yüksek Mahkemeye başvurabilir; bu da bir işlem için en baştan tüm doğrulayıcıların mutabakatını aramaya benzer.

Gas maliyetlerini karşılamak için ek GEN tokenları sağlayan herkes itiraz başlatabilir. Bu açık itiraz düzeni, sistemin kendi hatalarını düzeltebilmesini sağlar. Bu durum, mahkeme sisteminde kanun yoluna başvuran tarafın rolüne benzetilebilir: Davasının daha üst bir mercide görülmesi için bu sürecin masraflarını karşılaması gerekir.

Kesinlik ile işlem kapasitesi arasında denge

GenLayer'ın öncelikli hedefi işlem hızı ya da işlem kapasitesi konusunda diğer blokzincirlerle yarışmak değil. Platform bunun yerine hassasiyete ve güvenilirliğe öncelik veriyor; tıpkı adaleti verimliliğin önünde tutan bir mahkeme sistemi gibi.

GenLayer'daki işlemler, itiraz penceresi hiçbir itiraz gelmeden kapandığında kesinleşmiş sayılır. İtiraz penceresi, paydaşlara işlemi incelemeleri ve gerekirse kaygılarını dile getirmeleri için yeterli zaman tanır. Örneğin parametrik sigorta örneğinde itiraz penceresi, ödemeler yapılmadan önce ilgili tarafların kasırganın karaya çıktığı iddiasına itiraz edebilmesini sağlar.

Bu yaklaşım diğer ağlara kıyasla daha uzun kesinlik sürelerine yol açabilir, ama her işlemin titiz bir doğrulama sürecinden geçmesini sağlar. Ağın işlem kapasitesi ve gecikmesi, doğruluk ve güvenlik ihtiyacıyla dengelenir.

Öznel bir dünyada konsensüs bulmak

Eşdeğerlik İlkesi'nden ve itiraz sürecinden güç alan GenLayer'ın Optimistic Execution (iyimser yürütme) modeli, öznel ve deterministik olmayan işlemlerde konsensüse varmak için sağlam bir çözüm sunuyor. GenLayer, geliştiricilerin kendi kullanım senaryoları için kabul edilebilir sonucun ne olduğunu tanımlamasına izin vererek geleneksel blokzincir platformlarında daha önce mümkün olmayan çok çeşitli uygulamaların önünü açıyor.

Giderek daha öznel hâle gelen bir dünyada yolumuzu bulmaya çalışırken GenLayer, deterministik olmamanın getirdiği zorluklarla baş edebilen, güvenilir ve güven gerektirmeyen sistemler kurmak için gereken araçları ve çerçeveyi sunuyor.

Editörün notu: Bu yazı Mart 2024 tarihlidir. GenLayer'ın bugün iki yanıtın ne zaman aynı sayılacağına nasıl karar verdiğini görmek için GenLayer Labs araştırma rehberini inceleyin.

Misyonumuza katılın!

Web sitesi | Blog | Discord | X (eski adıyla Twitter) | Telegram | Simulator | Dokümantasyon | Whitepaper