Yaklaşan Hard Fork’umuzun Detayları—PoS Katmanının Eklenmesi Dahil
Conflux Network’ün yaklaşmakta olan hardfork’u 6 CIP (Conflux İyileştirme Önerileri) içerecektir: CIP-43, CIP-64, CIP-71, CIP-72, CIP-76 ve CIP-78. Aşağıda her bir teklifin bir özeti bulunmaktadır.
Özet
Stake edilen CFX sahipleri arasında oylama yoluyla Conflux zincirine kesinlik getirmeyi öneriyoruz. Bu, Conflux’ta gerçekleşen yüksek değerli işlemlerin güvenini artıracak ve Conflux’u PoW’dan gelen olası %51 saldırılarına karşı koruyacaktır.
Abstract
Proof of Work(POW) Ağacı-Grafik yapısının sürecini izleyen ve PoW onay kuralı kapsamında onaylanmış pivot blokları için bir fikir birliğine ulaşan bağımsız bir Proof of Stake zinciri tanıtın. PoS zinciri, bir pivot bloğu onayladığı zaman, tüm PoW madencileri onu takip etmelidir. Bu, Conflux zincirini PoW kaynaklı uzun menzilli %51 saldırılarından etkili bir şekilde koruyacaktır.
CFX sahipleri, PoS zincirinde oy hakkı talep etmek için belirli bir sözleşmeye para yatırabilir. PoS zinciri, oy haklarına sahip düğümleri seçmek için Doğrulanabilir bir rastgelelik kaynağı kullanır. Komite geçicidir ve her altı saatte bir periyodik olarak dönecektir. Şartlar kademelidir, komite koltuklarının yaklaşık altıda biri her saat seçime hazırdır (Bu TYP'nin tasarımı nispeten karmaşıktır ve parametreler için daha sonra bir ayarlama yapılabilir). Faiz, yalnızca PoS zincirinde stake edilerek oluşturulabilir. Ekonomik modelle ilgili daha fazla ayrıntı gelecek.
Motivasyon
Bir kamu zincirinin ekolojik gelişiminin ilk aşamasında, toplam hesaplama gücü miktarı nispeten yetersizdir. Bu, %51 saldırıları başlatmak ve çift harcama yaparak zincirdeki fonları çalmak için düşük bir saldırı maliyeti sağlar. Geçen yıl, Ethereum Classic, Grin ve Verge %51 saldırılarına maruz kaldı. Saldırganın tehdidini azaltmak için, PoW düğümlerinin izlemesi gereken onaylanmış pivot blokları öneren bir stake komitesi oluşturan PoS kesinliği ekliyoruz.
Güvenlik
Bir PoW konsensüs mekanizması, saldırgan <%50 bilgi işlem gücünü kontrol ettiğinde genellikle güvenlik sağlar. Ancak CIP-43’ü etkinleştirdikten sonra durum nedir? İşte açıklamaya yardımcı olacak bazı senaryolar.
**51% Attack**
Saldırgan >%51 bilgi işlem gücünü kontrol ediyorsa ve PoS zinciri iyi çalışıyorsa, PoS zinciri tarafından kararlaştırılan pivot blokları hala güvenlidir. Ancak, PoS düğümleri yeni blokları onaylayamadığı için PoW zinciri canlılığını kaybedebilir. Saldırgan kaybolursa, fikir birliği protokolü her zamanki gibi yürütülebilir.
**17% Staking Attack**
Saldırgan >%17 komite üyelerini kontrol ederse, PoS zinciri canlılığını kaybedebilir. Ardından Conflux zinciri, CIP-43 etkinleştirilmemiş gibi çalışır. Saldırgan kaybolursa, fikir birliği protokolü her zamanki gibi yürütülebilir.
**84% Staking Attack**
Saldırgan >%84 komite üyelerini kontrol ederse, çakışan PoS blokları oluşturabilir. Bu durumda, saldırgan ortadan kaybolsa bile PoW zinciri ayrılacaktır.
**Long-range attack**
%84 stake saldırısından farklı olarak, uzun menzilli bir saldırıda, bir PoS düğümü, fikir birliğini bozmayı amaçladığı için değil, özel anahtarları kaybettiği için kötü niyetli hale gelir. Bu nedenle, saldırganın yalnızca çok erken bir aşamada çoğunluk komitesini kontrol edebileceğini varsayıyoruz. Saldırgan >%51 bilgi işlem gücünü kontrol ediyorsa ve PoW zincirini erken aşamadan geri alabilirse, çift harcamalı bir saldırı gerçekleşir. Aksi takdirde, konsensüs protokolü yürütülebilir.
Basit Özet
Şu anda, Conflux üzerindeki işlemlerin, yürütüldükleri dönemin sayısına doğrudan erişimi yoktur. EVM uyumluluğunu korumak için bu CIP, bu bilgileri sözleşmeler için kullanılabilir hale getiren yeni bir dahili sözleşme sunar.
Abstract
Dapp geliştirmede yaygın bir teknik, bir olaya karşılık gelen blok numarasını bir sözleşmenin deposunda saklamak ve ardından bu bilgiyi sözleşmeyi sorgulamak için kullanmaktır. Örneğin, sözleşmenin oluşturulmasından başlayarak günlükleri sorgulamaya başlamak isteyebilirsiniz. Ancak, Conflux'un sorgu API'leri blok numaralarıyla değil, dönem sayılarıyla çalışır, bu da bu tekniği olanaksız kılar. Bu CIP, yürütme dönemi numarasını sözleşmeler için kullanılabilir hale getiren yeni bir dahili sözleşme sunar.
Motivasyon
Akıllı sözleşmelerde blok numaralarını ("block.number") kullanmanın iki yaygın kullanım durumu vardır.
- İlk kullanım durumu zamanlamadır. Blok numaralarının büyüme hızı nispeten sabittir ve etkilenmesi zordur, bu da onları zaman kilitleri gibi uygulamalar için uygun hale getirir.
- İkinci kullanım durumu sorgulamadır. Örneğin, bir sözleşme, oluşturma blok numarasını saklayabilir ve müşteriler, sözleşmenin olaylarını sorgulamaya başlamak için hangi bloktan başlamaları gerektiğini bilmek için bunu okuyabilir.
Sorgu API'lerimiz (RPC) blok numarasına göre değil, yalnızca dönem numarasına göre sorgulamayı desteklediğinden, bu son kullanım durumu Conflux'ta mümkün değildir.
Basit Özet
Sözleşme geliştiricisinin, sözleşmeleri için yeniden giriş önlemeyi devre dışı bırakmasına izin verin.
Abstract
Şu anda, Conflux VM'nin bir yeniden giriş önleme mekanizması vardır. Çağrı yığınında bir sözleşme iki kez göründüğünde, Conflux "SSTORE", "LOG0" ila "LOG4" ve "CALL" gibi sonraki tüm yazma işlemlerini sıfır olmayan bir bakiyeyle yasaklayacaktır. Bu CIP, bu özelliği yapılandırılabilir hale getirmeyi amaçlar. Yeni bir dahili sözleşme tanıtılmalı ve sözleşmenin kendisinin veya yöneticisinin bu özelliği açmasına veya kapatmasına izin vermelidir.
Motivasyon
Conflux, Defi uygulamalarına yönelik bazı saldırıları önlemek için bir yeniden giriş önleme mekanizması sunar. Ancak, bu aynı zamanda bazı geçerli işlemleri de yasaklayacaktır. Örneğin, bir borçlu sözleşmesi bir geçici kredi sözleşmesi çağırıyorsa ve geçici kredi sözleşmesi borçlu sözleşmesinin "geri arama" işlevini çağırıyorsa. Ardından, ödünç alan sözleşmesi çağrı yığınında iki kez görünecek ve sonraki tüm yazma işlemleri yasaklanacaktır. Geliştiriciler, sözleşmeler arasındaki etkileşim mantığını değiştirerek bu sorunu önleyebilse de, bu, sözleşme geçişi için ek görevler sunar.
Conflux, yalnızca çağrı yığınında yeniden girişe izin vermeyen bir sözleşme adresi iki kez görünürse yazma işlemlerini (yeniden giriş önleme mekanizmasını tetikler) yasaklayacaktır
Basit Özet
Metamask gibi Ethereum cüzdanlarındaki imzaları tanımak ve kabul etmek için Conflux.
Abstract
Conflux, Ethereum'dan farklı bir işlem formatına sahiptir, bu nedenle Metamask, Conflux tarafından kabul edilen bir işlem imzası üretemez. Bu CIP, Conflux'un 'u64::MAX' hedef dönemi olan işlemleri Ethereum tipi işlem olarak ele almasını planlıyor ve işlemleri doğrulamak için farklı bir yol kullanıyor.
Motivasyon
Bu CIP, kullanıcıların Conflux zincirindeki akıllı sözleşmelerle Metamask gibi Ethereum cüzdanlarıyla etkileşime girmesine izin verecek. Bunun Conflux zincirini deneyimlemek için daha fazla kullanıcı çekebileceğine inanıyoruz.
Güvenlik Hususları
Kötü niyetli bir aktarıcı, Ethereum benzeri işlemi kurcalamaya çalışırsa, imza doğrulamasını geçerek bunu farklı bir işleme dönüştüremez
Basit Özet
Senkronizasyon bloklarındaki VM ile ilgili kısıtlamaları, işlemlerin yeterli gaz limitine sahip olmasını istemek gibi kaldırmalıyız.
Abstract
Şu anda, senkronizasyon grafiklerine yeni bloklar eklemeden önce birkaç kısıtlamayı kontrol ettik. Bunlardan biri, işlem gaz limitinin minimum eşiği aşmasını gerektirir. Ancak bu eşik, sanal makinenin gelecekteki yükseltmelerde değişebilecek olan gaz planına dayanır. Bu CIP, blokları eşitlemede VM ile ilgili kısıtlamaları kaldırmayı ve gelecekte benzer kuralların getirilmesinden kaçınmayı önerir.
Motivasyon
Konsensüs bileşenini yürütme bileşeniyle ayırmak, sonraki yükseltme planları için hayati önem taşır.
Konsensüs protokolü, yürütme bileşenine karşı şeffaf olmalıdır. Bununla birlikte, senkronizasyon grafiği, alınan bir bloğun geçerliliğini kontrol ederken VM ile ilgili parametreleri okursa, VM seviyesindeki herhangi bir değişiklik, konsensüs protokolünde bir hard fork'a neden olabilir.
İşlem gaz limiti kısıtlaması, kötü niyetli bir madencinin gereksiz işlemler içeren bir bloğu doldurmasını engelleyemez çünkü gönderenin gaz ücretini ödemek için yeterli bakiyesi olup olmadığını kontrol etmiyoruz.
Kötü niyetli madenci, gönderenin bakiyesi sıfır olan birçok işlemi paketleyebilir.
Şartname
Belirli bir dönem yüksekliğinden sonra, fikir birliği protokolü artık işlemler için blok yüksekliklerini kontrol etmez.
Güvenlik Hususları
Motivasyon bölümünde anlatıldığı gibi, mevcut uygulama kötü niyetli bir madencinin bir blokta gereksiz işlemleri tamamlamasını engelleyemez. Yani bir kısıtlamayı kaldırmak onu daha da kötüleştirmez.
Basit Özet
İşlem makbuzundaki yanlış alanları düzeltin.
Abstract
Şu anda, işlem makbuzu, sponsor gaz ücretini fiilen ödemiş olsa bile, yürütme başarısız olduğunda işlemin sponsorlu olmadığını gösterir. Ayrıca, sponsor saklama teminatı için yeterli bakiyeye sahip olmadığında, gönderici saklama teminatı alacaktır.Ancak makbuz, işlemin sponsorlu olduğunu kaydeder.
Motivasyon
Ne olursa olsun, işlem makbuzundaki "is_sponsorlu" alanları sponsorun ödeme yapması durumunda her zaman tutarlı olmalıdır.
Conflux üzerindeki işlemler, yürütüldükleri dönemin sayısına doğrudan erişime sahip olacaktır. EVM uyumluluğunu korumak için bu CIP, bu bilgileri sözleşmeler için kullanılabilir hale getiren yeni bir dahili sözleşme sunar.
Sözleşme geliştiricisinin, sözleşmesi için yeniden giriş önlemeyi devre dışı bırakmasına izin verin.
Conflux, Ethereum’un Metamask gibi cüzdanlarından gelen imzaları kabul edecektir.
İşlemlerin yeterli gaz sınırına sahip olmasını istemek gibi, eşitleme bloklarındaki VM ile ilgili kısıtlamaları kaldıracağız
İşlem makbuzundaki yanlış alanları düzeltin.
iletişim:
| web sitesi | twitter | medium | YouTube | Telgram | whaitpaper | discord | github | Reddit | Forum |
