Parçalama Teknolojisi: Blok Zinciri Ölçeklenebilirliğinin Sınırları

15 Eylül 2022'de, Ethereum birleşimi (Merge) tamamladı. Bu tarihi bir an, Ethereum bunun için 5 yıl hazırlandı, 6 kez ertelendi. Sürekli ayarlamalar ve uzun süreli geliştirme ile birlikte, büyük bir dikkat ile birçok insan birleşimin doğal olarak daha yüksek ölçeklenebilirlik, güvenlik ve sürdürülebilirlik getireceğini düşündü, ancak gerçekte böyle değildir. PoW( iş kanıtı)'ndan PoS( hisse kanıtı)'na geçiş, sadece "raylar ve tekerlekler" değiştirildi, doğrudan daha hızlı hız, daha büyük kapasite veya daha düşük maliyetler getirmeyecek. Bu hedefleri gerçekten gerçekleştirebilecek olan, parçalama kapasitesine sahip bir ana ağ ile artırılmış ölçeklenebilirlik sağlayan Layer2 çözümlerinin bir bütün setidir.

Ethereum'un kurucusu Vitalik Buterin'in belirttiği gibi, parçalama, ölçeklenebilirlik üçlemesinin bir çözümüdür. Ağa bağlı düğümleri daha küçük gruplara ayırarak, farklı işlem setlerini işleyip paralel işlem yapmayı sağlar. Bu, bir süpermarkette alışveriş yaparken birden fazla kasa açarak bekleme süresini azaltmak ve ödeme verimliliğini artırmak gibidir.

Bu, parçalamanın mantığıdır, doğrudan ve basittir. Ancak, şeytan ayrıntılardadır - ilke ve yön doğru, fakat uygulamada her zaman birçok sorunla karşılaşılır. Bu makale, "parçalama" yolundaki yönleri ve tuzakları belirlemeyi, yıldızlara bakmayı ve yere sağlam basmayı hedefleyen bir parçalama keşif haritası çizmeyi amaçlamaktadır. Aynı zamanda mevcut parçalama çözümlerini karşılaştırarak bazı ortak sorunları bulmayı ve uygulanabilir bir keşif yönü önerisi sunmayı hedeflemektedir: Shardeum ve dinamik parçalama.

Bir, "Parçalama" Hakkında

Kısaca, imkansız üçgenin kısıtlamalarını göz önünde bulundurarak, Ethereum'u koordinat sistemi başlangıcı ( ve 0) olarak alarak, "dikey" ve "yatay" iki düşünce tarzına göre, mevcut Blok Zinciri'nin ölçeklenebilirlik yöntemlerini iki ana kategoriye ayırıyoruz:

Dikey Ölçekleme(Vertical Scaling): Mevcut sistem donanımının performansını artırarak gerçekleştirilir. Her bir düğümün süper hesaplama gücüne sahip olduğu merkeziyetsiz bir ağ oluşturmak, yani her düğüm "daha iyi" donanıma ihtiyaç duyar. Bu yöntem basit ve etkili olup, özellikle yüksek frekanslı ticaret, oyun ve gecikmeye duyarlı diğer uygulama senaryoları için, işlem hacminin başlangıçta iyileştirilmesine olanak tanır. Ancak bu ölçekleme yöntemi, ağın merkeziyetsiz seviyesini kısıtlar, çünkü doğrulama düğümleri veya tam düğümleri çalıştırmanın maliyeti artar. Merkeziyetsiz seviyesinin sürdürülmesi, hesaplama donanımının performansındaki genel büyüme hızına bağlıdır( bu da "Moore Yasası" olarak adlandırılır: Çip üzerindeki transistör sayısı her iki yılda bir iki katına çıkar, hesaplama maliyeti ise yarıya iner).

Horizon Genişletme (Horizon Scaling ): Horizon genişletmenin genellikle birkaç düşünce tarzı vardır. Bir tanesi, blok zinciri bağlamında, belirli bir ekosistemdeki işlem hesaplama miktarını birden fazla bağımsız blok zincirine dağıtmaktır; her bir zincir kendi blok üreticisine ve yürütme yeteneğine sahip olup, bu yöntem her bir zincirin yürütme katmanını tamamen özelleştirmeye olanak tanır. Örneğin, düğüm donanım gereksinimleri, gizlilik işlevleri, gas ücretleri, sanal makineler ve izin ayarları gibi. Diğer bir yatay genişleme çözümü, blok zincirinin temel altyapısını yürütme katmanı, veri kullanılabilirliği katmanı (DA) ve konsensüs katmanı olarak bölmektir. En yaygın blok zinciri modüler mekanizması rollup'tır. Bir diğer yöntem ise bir blok zincirini birçok parçaya ayırmak ve paralel olarak çalıştırmaktır. Her bir parça bir blok zinciri olarak görülebilir; yani birçok blok zinciri paralel olarak çalışabilir. Ayrıca genellikle tüm parçaları senkronize tutmak için tek bir ana zincir bulunur.

Şunu belirtmek gerekir ki, yukarıdaki ölçeklendirme yaklaşımları birbirinden bağımsız değildir; her bir çözüm, imkânsız üçgen içinde bir denge noktası bulmakta, sistemdeki ekonomik güçlerin yarattığı teşvik mekanizması tasarımı ile makro ve mikro düzeyde etkili bir denge sağlamakta.

"Parçalama" konusunu tartışmak için, her şeyi baştan itibaren düzenlememiz gerekiyor.

Hala böyle bir senaryo varsayalım, süpermarket alışverişi ödeme sırasında, ödeme verimliliğini artırmak ve müşteri bekleme süresini azaltmak için, tek bir ödeme noktasından 10 ödeme penceresine genişliyoruz, hesap hatalarını önlemek için, bu noktada ortak kurallar belirlememiz gerekiyor:

İlk olarak, 10 kasiyerimiz varsa, onları hangi pencerede çalışacak şekilde dağıtmalıyız?

İkinci olarak, eğer 1000 müşteri sırada bekliyorsa, her müşterinin hangi pencereden ödeme yapacağına nasıl karar verebiliriz?

Üçüncüsü, bu 10 pencereye karşılık gelen 10 ayrı defteri nasıl toplamalıyız?

Dördüncü olarak, muhasebe uyuşmazlıklarının önlenmesi için kasiyerlerin hata yapmasını nasıl engelleyebiliriz?

Bu birkaç soru aslında Parçalama içindeki bazı anahtar sorulara karşılık geliyor, sırasıyla:

Tüm ağ üzerindeki düğümlerin/doğrulayıcıların hangi parçalamaya ait olduğunu nasıl belirleyebilirim? Yani: (Ağ Parçalama) nasıl yapılır;

Her bir işlemin hangi parçaya tahsis edileceğini nasıl belirleyebiliriz? Yani: İşlem parçalama (Transaction Sharding);

Blok Zinciri verileri farklı Parçalama içinde nasıl depolanır? Yani: nasıl durum parçalama (State Sharding) yapılır;

Karmaşıklık risk anlamına gelir, yukarıdaki tüm temeller üzerinde, tüm sistem güvenliğinin bölünmesinden nasıl kaçınılabilir?

01 Ağ Parçalama (Network Sharding )

Eğer blok zincirini basitçe merkezi olmayan bir defter olarak anlarsak, PoS veya PoW konsensüs mekanizmaları, her bir düğümün belirli bir kurallar dizisine göre muhasebe hakkı için rekabet etmesini sağlamak içindir. Bu süreçte defterin doğruluğunu garanti eder. Ağ parçalama ise, blok zinciri ağını parçalamak için başka bir belirli kural gerektirir ve mümkün olduğunca birbirleriyle iletişimi azaltarak, her bir parça zincir üzerindeki işlemleri işleyerek muhasebe hakkı için rekabet eder - yani, düğümlerin gruplama kuralları.

Ve bu süreçte karşılaşılan sorun, Blok Zinciri içindeki düğümlerin farklı Parçalara ayrılmasıyla birlikte, saldırganların zorluk ve maliyetinin doğrudan düşmesidir. Bu gruplaşma sürecinin kurallarının ve sonuçlarının sabit ve öngörülebilir olduğunu varsayarsak, saldırganın tüm Blok Zinciri ağını kontrol etmek istemesi durumunda, yalnızca belirli bir parçayı hedef alması ve o parçada bulunan bazı düğümleri satın alması yeterli olacaktır.

Parçalama sistemi, ağın dış parçalardan bu işlemleri geri döndürmeyeceğine güvenmek için bir mekanizma geliştirmelidir. Şimdiye kadar, en iyi cevap, parçalama içinde doğrulayıcı sayısının belirli bir minimum eşik değerinin üzerinde olmasını sağlamaktır, böylece dürüst olmayan doğrulayıcıların tek bir parçayı aşma olasılığı çok düşük olacaktır. En yaygın yöntem, belirli bir düzeyde önyargısız rastgelelik oluşturmaktır; bu da matematiksel bir şekilde, saldırganın başarılı olma olasılığını en aza indirmeye dayanır. Örneğin, Ethereum, Ethereum'un çözümü, tüm doğrulayıcılardan rastgele bir parçanın doğrulayıcısını seçmektir ve her 6.4 dakikada ( bir epoch uzunluğu ) doğrulayıcıları değiştirmektedir.

Basitçe söylemek gerekirse, düğümleri rastgele gruplara ayırmak ve ardından işleri her grup düğümüne bağımsız olarak doğrulamak için atamaktır.

Ancak belirtmek gerekir ki, Blok Zinciri'ndeki rastgelelik oldukça zorlu bir konudur; mantıken, bu rastgele sayının üretim süreci herhangi bir belirli parçalamanın hesaplamasına bağlı olmamalıdır. Bu hesaplama için mevcut birçok tasarım düşüncesi, tüm ağı koruyan ayrı bir Blok Zinciri geliştirmektir. Böyle bir zincir Ethereum ve Near'de Beacon zinciri, PolkaDot'ta Relay zinciri, Cosmos'ta ise Cosmos Hub olarak adlandırılmaktadır.

02 İşlem Parçalama ( Transaction Sharding )

İşlem parçalama, "hangi işlemlerin hangi parçalara atanacağı" ile ilgili kuralların belirlenmesi anlamına gelir, böylece hem paralel işleme amacı sağlanabilir hem de çift harcama sorunlarının ortaya çıkması önlenebilir. Blok Zinciri'nin defter modelindeki farklılıklar, işlem parçalamanın geliştirilmesini etkileyebilir.

Şu anda Blok Zinciri ağında iki tür muhasebe yöntemi bulunmaktadır, bunlar UTXO( Kullanılmamış İşlem Çıktıları ve hesap/bakiye modelidir. İlkinin tipik bir temsilcisi BTC, ikincisi ise ETH'dir.

UTXO modeli: BTC işlemlerinde her işlem bir veya daha fazla çıktıya sahip olur, UTXO henüz harcanmamış blok zinciri işlemlerinin çıktısını ifade eder ve yeni işlemlerin girişi olarak kullanılabilir, harcanmış işlem çıktıları ise tekrar harcanamaz, kağıt para işlemlerindeki ödeme ve bozdurma durumuna benzer, müşteri bir veya daha fazla kağıt parayı dükkana öder, dükkandaki kişi de bir veya daha fazla kağıt parayı müşteriye bozdurur. UTXO modelinde, işlem parçalamaları arasında çapraz parçalama iletişimi gereklidir. Bir işlem birden fazla girdi ve birden fazla çıktı içerebilir, hesap kavramı yoktur ve bakiye kaydı da olmayacaktır, olası bir yol şudur: İşlemin belirli bir girdi değerine göre onu bir hash fonksiyonu ile işleyip verinin hangi parçaya gitmesi gerektiğini belirlemek için ayrık bir hash değeri elde etmek.

Girişlerin tutarlı bir şekilde doğru Parçalama içinde yer almasını sağlamak için, Hash fonksiyonuna girilen değerlerin aynı sütundan gelmesi gerekir. Bu sütuna Shard Key denir. Daha sonra, 1 değerini üreten işlemler Parçalama 1'e, 2 değerini üreten işlemler Parçalama 2'ye ayrılır. Ancak bu yöntemin dezavantajı, Parçalama arasında çift harcama saldırılarını önlemek için iletişim kurulması gerektiğidir. Çift Parçalama işlemlerini sınırlamak, platformun kullanılabilirliğini kısıtlayacaktır; Parçalama arası işlemlere izin vermek ise Parçalama arası iletişim maliyetleri ile performans artışının getireceği faydalar arasında bir denge kurmayı gerektirir.

Hesap/Bakiye Modeli: Sistem, her hesabın bakiyesini kaydeder. İşlem yaparken, sistem, hesabın ödemeyi yapmak için yeterli bakiyeye sahip olup olmadığını kontrol eder; bu, bankanın her hesabın bakiyesini kaydettiği banka havalesine benzer. Sadece hesap bakiyesi, gerekli havale tutarından büyükse işlem gerçekleştirilebilir. Hesap/bakiye modelinde, bir işlemin yalnızca bir girişi olduğu için, işlemin gönderici adresine göre parçalanması yeterlidir, bu da aynı hesabın birden fazla işleminin aynı parçalama içinde işlenmesini garanti eder ve çift harcama olasılığını etkili bir şekilde önler. Bu nedenle, parçalama teknolojisini kullanan çoğu blok zinciri, Ethereum gibi bir hesap defteri sistemidir.

![万字详解新公链 Shardeum：Parçalamanın başka bir olasılığı])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(

) 03 Durum Parçalama ### State Sharding (

Durum parçalama, blok zinciri verilerinin farklı parçalarda nasıl dağıtıldığını ifade eder.

Hala süpermarketimizdeki kuyruk örneğini kullanarak, her pencerede bir hesap var, pencerelerin defterleri nasıl kaydediliyor? Eğer: bir müşteri hangi sıraya gelirse, o hesabı kaydediyor, mesela A müşterisi A penceresine gitti, o zaman ertesi gün o müşteri başka bir ödeme penceresine gitti, mesela B penceresi, ama B penceresinin o müşterinin geçmiş hesap bilgileri yok ), örneğin bir değerli kart gibi ödeme yöntemleri ( söz konusu olduğunda, ne olmalı? A penceresinden o müşterinin hesap bilgilerini mi çağırmalı?

Durum parçalama, parçalamanın en büyük sorunudur ve yukarıda bahsedilen ağ parçalama ve işlem parçalamadan daha zordur. Çünkü parçalama mekanizmasında, işlemler adreslere göre farklı parçalarda işlenir, yani durum yalnızca adresinin bulunduğu parçada saklanır. Bu durumda karşılaşılması gereken bir sorun, işlemlerin sadece bir parçanın içinde gerçekleşmediğidir; sık sık çapraz parçalama )Cross-Sharding( ile ilgilidir.

Bir transfer durumunu düşünün; A hesabı B hesabına 10U gönderiyor ve A'nın adresi Parçalama 1'de tahsis edilmiş, işlemin kaydı da Parçalama 1'de saklanacak. B'nin adresi Parçalama 2'de tahsis edilmiş, işlemin kaydı da Parçalama 2'de saklanacak.

Bir A, B'ye transfer yapmak istediğinde, bir çapraz parçalama işlemi oluşur, Parçalama 2, Parçalama 1'den geçmiş işlem kayıtlarını çağırarak işlemin geçerliliğini onaylar. Eğer A, B'ye sık sık para gönderirse, Parçalama 2, Parçalama 1 ile sürekli etkileşimde bulunmak zorunda kalır, bu da işlemlerin işlenme verimliliğini düşürür. Ancak, belirli bir parçalamanın tüm tarihini indirmeden ve doğrulamadan, katılımcılar arasındaki etkileşimin bazı geçerli blok dizilerinin sonucu olup olmadığını kesin olarak bilemezler ve böyle bir blok dizisinin gerçekten parçalama içindeki standart zincir olup olmadığını da bilemezler.

Bu nedenle, parçalama yapılmayan tek bir zincirle karşılaştırıldığında, parçalama sisteminin karşılaştığı yeni zorluk, kullanıcıların herhangi bir belirli zincirin geçerliliğini ve kullanılabilirliğini doğrudan tamamen doğrulayamamalarından kaynaklanmaktadır, çünkü veri çok fazladır. Kullanıcılara hangi zincirin tamamen kullanılabilir ve geçerli olduğunu doğrulamak için en yüksek derecede güvensiz ve pratik dolaylı yöntemler sağlanmalıdır, böylece hangi zincirin standart zincir olduğunu belirleyebilirler. Pratikte, blok zinciri geliştiricileri doğrulama ile ilgili bazı sorunları çözmek için aşağıdaki teknikleri kullanabilir: komiteler, SNARK'lar/STARK'lar, balıkçı mekanizmaları ve dolandırıcılık ve veri kullanılabilirliği kanıtları gibi.

Bu sorunu çözmek için iki yaklaşım vardır, biri parçalama üzerinden senkronizasyon.