Deneyimli kullanıcılar bile bazı daha karmaşık kripto jargonlarını kavramakta zorluk çekebilir. Bazen hikayelerinde bloblar ve Bizans Hata Toleransı rahatça anıldığında sadece kafa sallamak zorunda kalırsınız. Hızlı buluşlarıyla tanınan bitcoin endüstrisi, zaman zaman deneyimli uzmanları bile sınayan karmaşık bir kelime dağarcığı yaratmıştır. Gelin bu sorunu bir kere ve sonsuza kadar çözelim.

Bu makale, blockchain ortamındaki en karmaşık ve genellikle yanlış yorumlanan yedi ifadeyi atomlarına ayırarak, dijital para için anlamları, kullanımları ve gelecekteki sonuçlarına dair kapsamlı bir araştırma sunmaktadır.

Bizans Hata Toleransı: Blockchain Güvenliğinin Temeli

Milyonlarca kripto meraklısının çoğu muhtemelen Bizans Hata Toleransı hakkında bir şeyler duymuştur. Ancak, bunların %99.9'u, makul bir şekilde ne olduğunu tanımlayamaz.

Genellikle, Bitcoin'in yaratılış tarihini inceleyen ve Satoshi Nakamoto'nun Bizans Hata Toleransı sorununu çözmek için madenciliği tam olarak kullandığını bulan bireyler de bunun ne olduğunu tam anlamıyla kavrayamazlar.

Sorunun madencilikle ilişkili olduğunu düşünmek geleneksel midir? Hayır, gerçekten değil.

Bizans Hata Toleransı (BHT), Bizans Generalleri Problemi olarak bilinen teorik bir bilgisayar bilimleri probleminden türeyen bir terimdir ve blockchain teknolojisi için kritiktir. İlk olarak 1982'de Leslie Lamport, Robert Shostak ve Marshall Pease tarafından sunulmuştur ve düşmanca ya da güvenilmez üyelerin olabileceği dağıtılmış bir sistemde uzlaşıya varmanın zorluklarına işaret eder.

Bizans Generalleri Probleminde, bir şehre saldırı koordine etmek için birden fazla general gereklidir. Sadece haberci aracılığıyla iletişim kurabilirler; bazı generaller planı baltalamaya çalışan hainler olabilir. Zorluk, etrafta hainler varken itaat eden generallerin hemfikir olmasını sağlayacak bir strateji geliştirmektir.

Blockchain bağlamında bizans hata toleransı, bir sistemin amacına uygun şekilde çalışmasını ve bazı bileşenlerinin başarısız olması veya kötü niyetli davranması durumunda bile uzlaşıya varabilmesini ifade eder. Dağıtılmış ağların bütünlüğünü ve güvenliğini sürdürmek buna bağlıdır.

Bitcoin'in anonim yazarı Satoshi Nakamoto, Proof-of-Work (PoW) konsensüs mekanizması yoluyla, bizans generalleri problemini dijital para birimleri için esasen çözmüştür. PoW'da madenciler zor matematiksel problemleri çözmek için rekabet eder; kazanan, bir sonraki blockchain bloğunu ekleme şansını elde eder. Bu yöntem hesapsal olarak pahalı olduğundan, madencilerin dürüst davranmak için büyük mali teşviki vardır.

PoW çözümü, çünkü:

1. Katılmanın maliyeti vardır ve bu da zararlı ya da kötü niyetli faaliyetleri caydırır.
2. Bulmacaların karmaşıklığı, tek bir varlığın ağı kolayca yönetemeyeceğini garanti eder.
3. En uzun zincir kuralı, doğru blockchain versiyonunu bulmak için basit bir yaklaşım sunar.

Bununla birlikte PoW, blockchain üzerindeki Bizans Generalleri Problemi için tek çözüm değildir. BFT'yi daha enerji verimli bir şekilde çözmek için yetkilendirilmiş kanıt-istek (DPoS) ve kanıt-istek (PoS) gibi başka konsensüs sistemleri oluşturulmuştur.

Örneğin, Ethereum, PoW'den PoS'e geçtiğinde, bazen "The Merge" olarak da bilinen, Gasper adlı bir BFT konsensüs yöntemi kullanmıştır. Casper FFG (PoS-tabanlı kesinlik sistemi) ile LMD-GHOST fork-seçme kuralını birleştirerek, Bizans Hata Toleransı'nın güçlü güvenceleri elde edilir, böylece enerji tüketimi büyük ölçüde azalır.

Blockchain sistemlerinin güvenilirliğini ve güvenliğini garanti eden temel fikirleri anlamak BFT'nin farkındalığına bağlıdır. Bu teknolojinin gelişmesiyle birlikte BFT'ye yönelik yeni yöntemler sürekli olarak ortaya çıkmakta, dolayısıyla dağıtılmış sistemlerin yönünü belirlemektedir.

Nonce: Kriptografik Yapboz Parçası

Nonce, bir çeşit blockchain saçmalığıdır. Bu şaka için üzgünüm. Diğerleri, belki bir ya da iki kez duymuş olabilir ve sadece bir güvenlik kodu bileşeni olduğunu düşünebilir, ancak madenciler ve geliştiriciler onun ne olduğunu bilir. Evet, bir dereceye kadar öyle.

Basit görünmesine rağmen, nonce fikri, özellikle Bitcoin gibi proof-of-work sistemlerinde, blockchain teknolojisi için oldukça önemlidir. "Nonce", "sadece bir kez kullanılan sayı" teriminin kısa bir biçimidir ve blockchain işlemlerini doğrulayıp doğrulamalarını sağlamak için temel bir parçadır.

Bitcoin madenciliğinde, bir nonce, blok başlığında bulunan 32-bit (4-bayt) bir alandır. Madenciler bu numarayı, blok başlığının hash'ini belirli gereksinimlere - daha özel olarak, ağın mevcut zorluk derecesi tarafından belirlenen hedef değerden daha az bir hash - karşılayan bir hash oluşturmak için kontrol eder.

Madencilik süreci şu şekilde işler: Bir madenci bekleyen işlemlerden bir blok derler.

Blok başlığı şu elementleri içererek oluşturulur:

• Sürüm numarası
• Önceki bloğun hash'i
• Merkle kökü (bloktaki tüm işlemleri temsil eden bir hash)
• Zaman damgası
• Zorluk hedefi
• Nonce (ilk olarak 0'a ayarlanır)

Madenci, SHA-256 algoritmasını kullanarak blok başlığını hash eder. Elde edilen hash zorluk kriterlerini karşılıyorsa, blok "çözülmüş" kabul edilir ve madenci onu ağa yayınlar. Hash kriterleri karşılamıyorsa, madenci nonce'u artırır ve tekrar dener.

Nonce uzayı—2^32 veya yaklaşık 4 milyar olasılık—tüketilene kadar geçerli bir hash bulunana kadar nonce'un artırılması ve yeniden hash edilmesi işlemi devam eder. Doğru hash bulunmadan nonce uzayı tükenirse, madenciler diğer blok başlığı bileşenlerini (örneğin zaman damgasını) değiştirebilir ve yeniden başlayabilir.

Nonce, birkaç önemli rol üstlenir.

Madencilerin belirli nonce'u bulmalarını gerektirerek, ağ madencilik zorluğunu değiştirebilir. Bu, toplam ağ hash gücündeki değişikliklerden bağımsız olarak blok zamanının—Bitcoin için yaklaşık 10 dakika—sabit kalmasını sağlar.

Nonce, PoW'da yapılan gerçek "çalışma"yı yapmak için madencilerin kontrol ettiği değişkendir. Doğru nonce'u bulmak, bir madencinin hesapsal kaynaklar kullandığını gösterir.

Blockchain'i manipüle etmeyi oldukça zorlaştırır çünkü bir bloğu çözecek nonce öngörülemez. Dürüst madencileri düzenli olarak geride bırakmak için, bir saldırganın ağın hash gücünün yarısından fazlasını kontrol etmesi gerekir.

Nonce, madencilere eşit bir oyun alanı sunar. Geçerli bir bloğu bulmak esasen rastgeledir ve bir madencinin sunduğu işlem kapasitesine bağlıdır.

Nonce fikri PoW sistemlerinde yaygın olarak bilinse de, diğer ortamlarda uygulanan versiyonları vardır. Örneğin, Ethereum işlemlerinde bir nonce, her işlemin yalnızca bir kez ve doğru sırayla işlenmesini garanti etmek için kullanılır.

Blockchain teknolojisi geliştikçe, nonce'ların işlevi değişebilir. Örneğin, kanıt-istek sistemlerinde PoW'da uygulandığı şekilde madencilik ve nonce kavramı bulunmaz. Yine de, birçok blockchain sisteminde güvenliği ve adaleti sağlamak için kullanılan değişken, bir kez kullanılan sayıların temel fikri önemli kalmaktadır.

Rollups: Katman-2 İşlemlerini Hızlandırma

DeFi dünyasında iseniz, muhtemelen rollups hakkında bir şeyler duymuşsunuzdur. Yine de bildiklerinizin çoğu, birinci katmanın üzerinde katman 2 çözümleriyle ilgili olabilir.

Evet, ama daha fazlası var.

Ethereum gibi blockchain sistemleri ölçeklenebilirlik ile mücadele ettikçe, rollups, işlem verimini artırmak ve ücretleri azaltmak için olası bir çözüm haline geldi. Rollups, ilk blockchain dışında (katman-1) işlem icrasını gerçekleştirirken işlem verilerini katman-1'de yayınlayan katman-2 ölçekleme yöntemleridir.

Rollups temelde birçok işlemi bir pakette toplayıp ana zincire sunma sürecidir. Bu yöntem, ana zincirin işlem yapması gereken veri hacmini önemli ölçüde azaltarak daha yüksek ölçeklenebilirliği teşvik eder.

Rollups genellikle iki türe ayrılır:

Optimistik rollups, bir sorun durumunda bir sahtekarlık kanıtı kullanarak hesaplamayı yürütür ve varsayılan olarak işlemlerin doğru kabul edildiğini varsayar. Önemli özellikler arasında:

• Genel hesaplama için ZKroll-ups'tan daha ucuz ve daha hızlıdır.
• Ethereum Sanal Makinesi (EVM) ile uyumluluk, mevcut Ethereum uygulamalarının daha kolay taşınmasını sağlar.
• Genellikle bir hafta süren bir meydan okuma dönemi, herhangi birinin işlem sonuçlarını sorgulamasına olanak tanır. Örnekleri Arbitrum ve Optimism'dir.

Sıfır bilgi (ZK) rollups, rolled-off işlemlerin doğruluğunu onaylayan kriptografik kanıtlar—geçerlilik kanıtları olarak bilinen—oluşturur. Başlıca özelliklerinden biri, geçerlilik kanıtlarının anında on-chain doğrulanmasının güçlü bir şekilde gerçekleşmesi nedeniyle daha hızlı kesinliktir. Beklenen roll-ups'tan potansiyel olarak daha yüksek ölçeklenebilirlik; daha karmaşık kriptografik sistemler nedeniyle bunların genel hesaplama için uygulanması daha zordur. Özellikle, iki örnek StarkNet ve zkSync'dir.

Roll-ups'un çeşitli faydaları vardır:

Roll-ups, işlem yükünü zincir dışına taşıyarak, ağın saniyede işleyebileceği işlem sayısını (TPS) önemli ölçüde artırabilir. Ana zincirde daha az veri işlenmesi gerektiğinden, işlem ücretleri düşer. Ana zincirde kritik veriler yer aldığı için rollups, ana zincirin güvenliğini devralır. Özellikle ZK-rolluplarında, işlem kesinliği ana zincire göre çok daha hızlı elde edilebilir.

Yine de rollups zorluklar da sunar:

Teknik zorluk: Roll-ups kullanımı—özellikle ZK-rollups—zorlayıcıdır. Roll-up operatörleri oldukça önemlidir ve merkezileşme etkisine neden olabilir. Optimistik rolluplarda kullanıcılar, meydan okuma aşaması nedeniyle parasını ana zincire çekmekte gecikme yaşayabilir.

Blockchain ekosistemi geliştikçe, roll-ups ölçekleme çözümlerinde daha belirgin hale gelecek. Ethereum 2.0 gibi projeler, yol haritalarının temel bileşeni olarak roll-up merkezli ölçeklenebilirliği içermeyi planladıkları için bu teknolojinin blockchain geleceğindeki önemini gösteriyor. Translate the following content from en to tr.

Content: Ethereum universe. Many consumers, meanwhile, cannot really understand what blobs are. And finally the word becomes one of those you wish you knew, but it's never a good time to explore the tech specs.

Ethereum evreni. Bu arada, birçok tüketici blobların ne olduğunu gerçekten anlayamaz. Sonunda kelime, öğrenmek istediğiniz ama teknoloji detaylarını keşfetmek için hiçbir zaman uygun olmayan bir terim haline gelir.

Let's fix it, then.

O zaman bunu düzeltelim.

Particularly in relation to the forthcoming Dencun upgrade—a mix of Deneb and Cancun upgrades—blobs, short for Binary Large Objects, mark a major shift in Ethereum's scaling road map.

Özellikle Deneb ve Cancun yükseltmelerinin bir karışımı olan yaklaşan Dencun yükseltmesiyle ilgili olarak, Binary Large Objects (ikili büyük nesneler) için kısaca bloblar, Ethereum'un ölçeklenme yol haritasında büyük bir değişikliği işaret eder.

Understanding blobs calls for exploring the technical sides of Ethereum's data management and path towards higher scalability.

Blobları anlamak, Ethereum'un veri yönetiminin teknik yönlerini ve daha yüksek ölçeklenebilirliğe giden yolu keşfetmeyi gerektirir.

Blobs in the Ethereum context are big amounts of data away from the execution layer—where smart contracts run—but nevertheless part of the Ethereum ecosystem. Designed as transitory, they stay on the network for eighteen to twenty-25 days before being thrown away.

Ethereum bağlamında bloblar, yürütme katmanından—akıllı sözleşmelerin çalıştığı yer—uzakta büyük miktarda veri olup yine de Ethereum ekosisteminin bir parçasıdır. Geçici olarak tasarlanmış olan bu veriler, atılmadan önce ağda on sekiz ila yirmi beş gün kalır.

Key characteristics of blobs include:

Blobların temel özellikleri şunlardır:

1. Size: Each blob can be up to 128 KB in size, significantly larger than the data typically included in Ethereum transactions.

   Boyut: Her bir blob, genellikle Ethereum işlemlerinde yer alan verilerden önemli ölçüde daha büyük olan 128 KB boyutunda olabilir.

2. Purpose: Blobs are primarily intended to serve layer-2 solutions, particularly rollups, by providing a more cost-effective way to post data on the Ethereum mainnet.

   Amaç: Bloblar, öncelikle veri Ethereum ana ağına göndermek için daha uygun maliyetli bir yol sağlayarak, özellikle rollup'lar olmak üzere katman-2 çözümlerine hizmet etmeyi amaçlar.

3. Verification: While blobs are not processed by the Ethereum Virtual Machine (EVM), their integrity is verified using a cryptographic technique called KZG commitments.

   Doğrulama: Bloblar Ethereum Sanal Makinesi (EVM) tarafından işlenmezken, bütünlükleri KZG taahhütleri olarak adlandırılan kriptografik bir teknik kullanılarak doğrulanır.

4. Temporary Nature: Unlike traditional blockchain data that is stored indefinitely, blobs are designed to be temporary, reducing long-term storage requirements.

   Geçici Doğa: Süresiz olarak depolanan geleneksel blok zinciri verilerinden farklı olarak bloblar, geçici olacak şekilde tasarlanmış ve uzun vadeli depolama gereksinimlerini azaltmaktadır.

Blobs are intimately related to the idea of "proto-danksharding," an intermediary stage toward complete sharding in Ethereum (we'll discuss this in a minute). Named for its proposers Protolambda and Dankrad Feist, proto-danksharding presents a novel transaction type (EIP-4844) allowing blob insertion.

Bloblar, Ethereum'da tam sharding'e (parçalama) giden bir ara aşama olan "proto-danksharding" fikriyle yakından ilişkilidir. Önericileri Protolambda ve Dankrad Feist'ten adını alan proto-danksharding, blob eklemeye izin veren yeni bir işlem türü (EIP-4844) sunar.

Here's how blobs work in the context of proto-danksharding:

Proto-danksharding bağlamında bloblar şöyle çalışır:

1. Layer-2 solutions (like rollups) generate transaction data.

   Katman-2 çözümleri (rollup'lar gibi) işlem verileri üretir.

2. This data is formatted into blobs.

   Bu veriler bloblara formatlanır.

3. The blobs are attached to special transactions on the Ethereum mainnet.

   Bloblar, Ethereum ana ağında özel işlemlere eklenir.

4. Validators and nodes verify the integrity of the blobs using KZG commitments, without needing to process the entire blob data.

   Doğrulayıcılar ve düğümler, tüm blob verilerini işlemeye gerek duymadan, blobların bütünlüğünü KZG taahhütlerini kullanarak doğrular.

5. The blob data is available for a limited time, allowing anyone to reconstruct the layer-2 state if needed.

   Blob verileri sınırlı bir süre boyunca mevcuttur ve gerekirse herkesin katman-2 durumunu yeniden yapılandırmasına izin verir.

6. After 18-25 days, the blob data is discarded, but a commitment to the data remains on-chain indefinitely.

   On sekiz ila yirmi beş gün sonra blob verileri atılır, ancak veri taahhüdü zincirde süresiz olarak kalır.

Blobs' introduction has various advantages:

Blobların tanıtımının çeşitli avantajları vardır:

1. Reduced Costs: By providing a more efficient way for rollups to post data on Ethereum, blob transactions can significantly reduce fees for layer-2 users.

   Düşük Maliyetler: Blob işlemleri, rollup'ların Ethereum üzerinde veri göndermesi için daha verimli bir yol sağlayarak, katman-2 kullanıcıları için ücretleri önemli ölçüde azaltabilir.

2. Increased Scalability: Blobs allow for more data to be included in each Ethereum block without increasing the computational load on the network.

   Artan Ölçeklenebilirlik: Bloblar, ağ üzerindeki hesaplama yükünü artırmadan, her Ethereum bloğuna daha fazla veri eklenmesine izin verir.

3. Improved Data Availability: While blob data is temporary, it ensures that layer-2 data is available for challenge periods in optimistic rollups or for users who need to reconstruct the layer-2 state.

   Geliştirilmiş Veri Erişilebilirliği: Blob verileri geçici olsa da, iyimser rollup'larda itiraz dönemleri veya katman-2 durumunu yeniden yapılandırması gereken kullanıcılar için katman-2 verilerinin erişilebilir olmasını sağlar.

4. Preparation for Sharding: Proto-danksharding serves as a stepping stone towards full sharding, allowing the Ethereum ecosystem to gradually adapt to new data management paradigms.

   Shardiğe Hazırlık: Proto-danksharding, tam sharding'e giden bir basamak taşı olarak hizmet eder ve Ethereum ekosisteminin yeni veri yönetimi paradigmalarına kademeli olarak uyum sağlamasına olanak tanır.

Blobs' introduction, meantime, also brings difficulties:

Bu arada, blobların tanıtımı aynı zamanda zorluklar da getirir:

1. Increased Bandwidth and Storage Requirements: Nodes will need to handle larger amounts of data, even if temporarily.

   Artan Bant Genişliği ve Depolama Gereksinimleri: Düğümler, geçici bile olsa daha büyük miktarda verileri işlemek zorunda kalacaktır.

2. Complexity: The addition of a new transaction type and data structure increases the overall complexity of the Ethereum protocol.

   Karmaşıklık: Yeni bir işlem türü ve veri yapısının eklenmesi, Ethereum protokolünün genel karmaşıklığını artırır.

3. Potential Centralization Pressures: The increased resource requirements might make it more challenging for individuals to run full nodes.

   Potansiyel Merkeziyetçilik Baskıları: Artan kaynak gereksinimleri, bireylerin tam düğümler çalıştırmasını daha zor hale getirebilir.

Blobs and proto-danksharding are a key component in balancing scalability, decentralization, and security as Ethereum keeps developing towards Ethereum 2.0. Blobs provide the path for a more scalable Ethereum ecosystem by offering a more efficient data availability layer, especially helping layer-2 solutions growingly significant in the blockchain scene.

Bloblar ve proto-danksharding, Ethereum 2.0'a doğru gelişirken ölçeklenebilirlik, merkezsizlik ve güvenliği dengelemekte kilit bir bileşendir. Bloblar, daha verimli bir veri erişilebilirlik katmanı sunarak, özellikle blokzinciri alanında giderek daha önemli hale gelen katman-2 çözümlerine yardımcı olarak daha ölçeklenebilir bir Ethereum ekosistemi için yol sağlar.

Proto-danksharding: Ethereum's Stepping Stone to Scalability

Proto-danksharding: Ethereum'un Ölçeklenebilirliğe Giden Basamak Taşı

Proto-danksharding was already mentioned above. Let's investigate it more closely.

Proto-danksharding yukarıda zaten bahsedildi. Şimdi bunu daha yakından inceleyelim.

Representing a major turning point in Ethereum's scalability road plan, it is sometimes known as EIP-4844 (E Ethereum Improvement Proposal 4844). Aiming to drastically lower data costs for roll-ups and other layer-2 scaling solutions, this idea—named for its proposers Protolambda and Dankrad Feist—serves as an intermediary toward true sharding.

Ethereum'un ölçeklenebilirlik yol planında önemli bir dönüm noktasını temsil eden bu, bazen EIP-4844 (Ethereum Geliştirme Önerisi 4844) olarak bilinir. Roll-up'lar ve diğer katman-2 ölçekleme çözümleri için veri maliyetlerini önemli ölçüde azaltmayı hedefleyen bu fikir, önericileri Protolambda ve Dankrad Feist'in adını taşıyan, gerçek sharding'e bir ara aşama olarak hizmet eder.

First one must comprehend sharding before one can grasp proto-danksharding.

Proto-danksharding'i kavramadan önce sharding'i anlamak gerekir.

Sharding is a method of database partitioning whereby a blockchain is broken out into smaller, more controllable shards. By means of parallel data storage and transaction processing, each shard can theoretically increase the capacity of the network. Implementing full sharding, however, is a difficult task requiring major modifications to the Ethereum protocol.

Sharding, bir blok zincirinin daha küçük, daha kontrol edilebilir parçalara bölündüğü bir veri tabanı parçalama yöntemidir. Paralel veri depolama ve işlem işlemi yoluyla, her bir parça teorik olarak ağın kapasitesini artırabilir. Ancak tam sharding uygulamak, Ethereum protokolünde büyük değişiklikler gerektiren zorlu bir görevdir.

Proto-danksharding brings many important ideas:

Proto-danksharding birçok önemli fikir getirir:

1. Blob-carrying Transactions: A new transaction type that can carry large amounts of data (blobs) that are separate from the execution layer.

   Blob-Taşıyan İşlemler: Yürütme katmanından ayrı büyük miktarda veri (blob) taşıyabilen yeni bir işlem türü.

2. Data Availability Sampling: A technique that allows nodes to verify the availability of blob data without downloading the entire blob.

   Veri Erişilebilirlik Örneklemesi: Düğümlerin, tüm blobu indirmeden blob verilerinin erişilebilirliğini doğrulamasına olanak tanıyan bir teknik.

3. KZG Commitments: A cryptographic method used to create succinct proofs of blob contents, enabling efficient verification.

   KZG Taahhütleri: Blob içeriğinin özlü kanıtlarını oluşturmak için kullanılan ve etkili doğrulama sağlayan bir kriptografik yöntem.

4. Temporary Data Storage: Blob data is only stored by the network for a limited time (18-25 days), after which it can be discarded while maintaining a commitment to the data on-chain.

   Geçici Veri Depolama: Blob verileri ağ tarafından yalnızca sınırlı bir süre (18-25 gün) için depolanır, ardından zincirde veri taahhüdünü muhafaza ederek atılabilir.

Proto-danksharding operates in this manner:

Proto-danksharding şöyle çalışır:

1. Layer-2 solutions (like rollups) generate transaction data.

   Katman-2 çözümleri (rollup'lar gibi) işlem verileri üretir.

2. This data is formatted into blobs (binary large objects).

   Bu veriler, bloblar (ikili büyük nesneler) biçimindedir.

3. The blobs are attached to special transactions on the Ethereum mainnet.

   Bloblar, Ethereum ana ağında özel işlemlere eklenir.

4. Validators and nodes verify the integrity of the blobs using KZG commitments, without needing to process the entire blob data.

   Doğrulayıcılar ve düğümler, tüm blob verilerini işlemeye gerek duymadan, blobların bütünlüğünü KZG taahhütlerini kullanarak doğrular.

5. The blob data is available for a limited time, allowing anyone to reconstruct the layer-2 state if needed.

   Blob verileri sınırlı bir süre boyunca mevcuttur ve gerekirse herkesin katman-2 durumunu yeniden yapılandırmasına izin verir.

6. After the retention period, the blob data is discarded, but a commitment to the data remains on-chain indefinitely.

   Saklama süresinden sonra blob verileri atılır, ancak veri taahhüdü zincirde süresiz olarak kalır.

Proto-danksharding has numerous important advantages:

Proto-danksharding birçok önemli avantaj sunar:

1. Reduced Costs: By providing a more efficient way for rollups to post data on Ethereum, blob transactions can significantly reduce fees for layer-2 users. This could potentially reduce costs by a factor of 10-100x.

   Düşük Maliyetler: Blob işlemleri, rollup'ların Ethereum üzerinde veri göndermesi için daha verimli bir yol sağlayarak, katman-2 kullanıcıları için ücretleri önemli ölçüde azaltabilir. Bu da maliyetleri potansiyel olarak 10-100 kat azaltabilir.

2. Increased Scalability: Blobs allow for more data to be included in each Ethereum block without increasing the computational load on the network. Ethereum's data capacity might so rise by up to 100x.

   Artan Ölçeklenebilirlik: Bloblar, ağ üzerindeki hesaplama yükünü artırmadan, her Ethereum bloğuna daha fazla veri eklenmesine izin verir. Böylece, Ethereum'un veri kapasitesi 100 kata kadar artabilir.

3. Improved Data Availability: While blob data is temporary, it ensures that layer-2 data is available for challenge periods in optimistic rollups or for users who need to reconstruct the layer-2 state.

   Geliştirilmiş Veri Erişilebilirliği: Blob verileri geçici olsa da, iyimser rollup'larda itiraz dönemleri veya katman-2 durumunu yeniden yapılandırması gereken kullanıcılar için katman-2 verilerinin erişilebilir olmasını sağlar.

4. Gradual Protocol Evolution: Proto-danksharding allows the Ethereum ecosystem to adapt to new data management paradigms gradually, paving the way for full sharding in the future.

   Kademeli Protokol Evrimi: Proto-danksharding, Ethereum ekosisteminin yeni veri yönetimi paradigmalarına kademeli olarak uyum sağlamasına olanak verir ve gelecekte tam sharding için yol açar.

However, implementing proto-danksharding also presents challenges:

Ancak, proto-danksharding'in uygulanması da zorluklar sunar:

1. Increased Complexity: The addition of a new transaction type and data structure increases the overall complexity of the Ethereum protocol.

   Artan Karmaşıklık: Yeni bir işlem türü ve veri yapısının eklenmesi, Ethereum protokolünün genel karmaşıklığını artırır.

2. Node Requirements: Nodes will need to handle larger amounts of data, even if temporarily, which could increase hardware requirements.

   Düğüm Gereksinimleri: Düğümler, geçici bile olsa daha büyük miktarda verileri işlemek zorunda kalacaktır ve bu da donanım gereksinimlerini artırabilir.

3. Potential Centralization Pressures: The increased resource requirements might make it more challenging for individuals to run full nodes, potentially leading to some degree of centralization.

   Potansiyel Merkeziyetçilik Baskıları: Artan kaynak gereksinimleri, bireylerin tam düğümler çalıştırmasını daha zor hale getirebilir ve bu da potansiyel olarak bazı merkeziyetçilik seviyelerine yol açabilir.

4. Ecosystem Adaptation: Layer-2 solutions and other Ethereum tools will need to be updated to fully leverage the benefits of proto-danksharding.

   Ekosistem Uyumu: Katman-2 çözümleri ve diğer Ethereum araçlarının, proto-danksharding'in avantajlarından tam anlamıyla yararlanabilmek için güncellenmesi gerekecektir.

A pivotal stage in Ethereum's development, proto-danksharding balances the demand for more scalability with the difficulties of putting intricate protocol updates into effect. A more scalable Ethereum environment is made possible by offering a more effective data availability layer.

Ethereum'un gelişiminde önemli bir aşama olan proto-danksharding, daha fazla ölçeklenebilirlik talebi ile karmaşık protokol güncellemelerinin uygulanmasının zorluklarını dengeler. Daha etkili bir veri erişilebilirlik katmanı sunarak, daha ölçeklenebilir bir Ethereum ortamının mümkün kılınması sağlanır.

Distributed Validator Technology (DVT): Enhancing Proof-of-Stake Security

Dağıtılmış Doğrulayıcı Teknolojisi (DVT): Hisse İspatı Güvenliğini Artırma

Validator technology has become a thing in the world of Ethereum since the Merge in 2022, when the Proof-of-Work protocol was ditched in favor of the Proof-of-Stake.

Doğrulayıcı teknolojisi, 2022'de İş Kanıtı protokolünün yerine Hisse İspatı lehine terk edilmesiyle Ethereum dünyasında bir gelişme haline geldi.

But many people still don’t understand how this technology works.

Ancak birçok insan hâlâ bu teknolojinin nasıl çalıştığını anlamıyor.

Maintaining network security and decentralization depends critically on the idea of Distributed Validator Technology (DVT). Particularly in networks like Ethereum 2.0, DVT marks a dramatic change in the way validators behave inside proof-of-stake systems.

Ağ güvenliği ve merkeziyetsizliği sürdürmek, kritik olarak Dağıtılmış Doğrulayıcı Teknolojisi (DVT) fikrine dayanır. Özellikle Ethereum 2.0 gibi ağlarda DVT, doğrulayıcıların hisse-kanıtı sistemlerindeki davranış biçimlerinde dramatik bir değişiklik teşkil eder.

Fundamentally, DVT lets one validator run several nodes, therefore dividing the tasks and dangers related to validation among several participants. This method contrasts with conventional validator configurations in which one entity oversees all facets of the validation process.

Temel olarak, DVT bir doğrulayıcının birden fazla düğüm çalıştırmasına olanak tanır, böylece doğrulamayla ilgili görevler ve tehlikeler birçok katılımcı arasında bölünür. Bu yöntem, tek bir varlığın doğrulama sürecinin tüm yönlerini denetlediği geleneksel doğrulayıcı yapılandırmalarıyla tezat oluşturmaktadır.

DVT's fundamental elements consist in:

DVT'nin temel unsurları şunlardır:

1. Validator Client: The software responsible for proposing and attesting to blocks.

   Doğrulayıcı İstemci: Blokları önermek ve onaylamaktan sorumlu yazılım.

2. Distributed Key Generation (DKG): A cryptographic protocol that allows multiple parties to collectively generate a shared private key.

   Dağıtılmış Anahtar Üretimi (DKG): Birden fazla tarafın ortak bir özel anahtar oluşturmasına olanak tanıyan bir kriptografik protokol.

3. Threshold Signatures: A cryptographic technique that enables a group of parties to collectively sign messages, with a certain threshold of participants required to create a valid signature.

   Eşik İmzalar: Bir grup tarafın mesajları topluca imzalamasına olanak tanıyan ve geçerli bir imza oluşturmak için belirli bir katılımcı eşiğinin gerektiği bir kriptografik teknik.

Usually, the DVT procedure proceeds this:

Genellikle, DVT prosedürü şu şekilde ilerler:

1. A group of operators come together to form a distributed validator.

   Bir grup operatör, dağıtılmış bir doğrulayıcı oluşturmak için bir araya gelir.

2. They use DKG to generate a shared validator key, with each operator holding a portion of the key.

   Her operatör anahtarın bir bölümüne sahip olacak şekilde DKG'yi kullanarak ortak bir doğrulayıcı anahtarı üretirler.

3. When the validator needs to perform an action (e.g., proposing or attesting to a block), a threshold number of operators must cooperate to sign the message.

   Doğrulayıcı bir eylem yapması gerektiğinde (örneğin, bir bloğu önermek veya onaylamak), belirli bir eşik sayısında operatörün mesajı imzalamak için iş birliği yapması gerekir.

4. The resulting signature is indistinguishable from one produced by a single validator, maintaining compatibility with the broader network.

   Ortaya çıkan imza, tek bir doğrulayıcı tarafından üretilenle ayırt edilemez ve daha geniş ağ ile uyumluluğu korur.

DVT has various important benefits:

DVT'nin çeşitli önemli faydaları vardır:Tek Nokta Arızası: Tek bir noktada meydana gelebilecek arıza dramatik bir şekilde azaltılmıştır. Bir operatör tehlikeye girse veya çevrimdışı kalsa bile, doğrulayıcı çalışmaya devam edebilir.

2. Artan Süreklilik Zamanı: Birden fazla operatörle, doğrulayıcının her zaman görevlerini yerine getirmek için kullanılabilir olma olasılığı büyük ölçüde artar, bu da potansiyel olarak daha yüksek ödüllere ve daha iyi ağ performansına yol açar.

3. Merkeziyetsizlik: DVT, daha küçük operatörlerin tüm riski üstlenmeden ve bir doğrulayıcıyı bağımsız olarak çalıştırma sorumluluğunu üstlenmeden doğrulama işlemi yapmasına olanak tanıyarak ağın daha merkeziyetsiz olmasını sağlar.

4. Ceza Kesme Koruması: Hisse ispatı sistemlerinde, doğrulayıcılar kötü davranışlar için cezalandırılabilir (kesilebilir). DVT, birden çok operatörün faaliyetlerde mutabık kalmasını gerektirerek yanlış dilimlemelerden kaçınmaya yardımcı olabilir.

Ancak, DVT aynı zamanda belirli zorluklar da sunar:

1. Karmaşıklık: DVT’nin uygulanması, doğrulayıcı operasyonlarına karmaşıklık katan karmaşık kriptografik protokoller ve birden çok taraf arasında koordinasyon gerektirir.

2. Gecikme: Birden fazla operatörün koordinasyon ihtiyacı, doğrulayıcı işlemlerinde potansiyel olarak gecikmeye neden olabilir, ancak bu durum uygun uygulamalarla azaltılabilir.

3. Güven Varsayımları: DVT, tek nokta arızalarını azaltırken, dağıtılmış bir doğrulayıcının operatörleri arasında güven gereksinimini getirir.

4. Düzenleyici Hususlar: DVT’nin dağıtılmış doğası, bazı yargı bölgelerinde düzenleyici uyumluluk ve sorumluluk konularında sorular ortaya çıkarabilir.

DVT, hisse ispatı ağları geliştikçe, güvenlik ve merkeziyetsizliğin korunmasında muhtemelen daha da önemli hale gelecektir. Ethereum 2.0 gibi projeler, DVT’nin dahil edilmesini aktif bir şekilde araştırmaktadır.

DVT’nin benimsenmesi, hisse ispatı ağlarının mimarisi üzerinde geniş etkileri olabilir ve güvenlik, merkeziyetsizlik ve erişilebilirliği dengede tutan yeni tür doğrulayıcı havuzları ve delegasyon türlerini oluşturabilir.

Dinamik Yeniden Parçalama: Uyarlanabilir Blok Zinciri Bölümlendirmesi

Son olarak, dinamik yeniden parçalamadan bahsedelim. Parçalama fikrine dayalı fakat ağın gerçek zamanlı değişen ihtiyaçlara tepki vermesine izin veren bir esnek katman ekleyen bu teknoloji, bir blok zinciri ölçeklenebilirlik yöntemi sunar.

Bazı blok zinciri meraklıları tarafından "parçalamanın kutsal kâsesi" olarak adlandırılan bu teknoloji, blok zinciri tasarımındaki en kalıcı sorunlardan birini çözmeyi vaat ediyor: ağ kapasitesi ile kaynak kullanımı arasında bir denge kurmak. Oldukça karmaşık görünüyor, değil mi?

Dinamik yeniden parçalamayı anlamak için öncelikle parçalamanın temellerini anlamak gerekir:

Blok zinciri sistemleri için uyarlanmış olan parçalama, bir veritabanı bölümlendirme yöntemidir. Blok zincirinin daha küçük, daha yönetilebilir parçalara bölünmesini içerir. Her parça, verileri paralel olarak depolayabilir ve işlemleri gerçekleştirebilir, bu da teorik olarak ağın kapasitesini artırır.

Dinamik yeniden parçalama, ağın mevcut ağ durumuna bağlı olarak parçaların sayısını ve düzenini değiştirmesine izin vererek bu fikri geliştirir.

Bu esnek strateji, bir dizi olası fayda sunar.

Ağ, yüksek talep dönemlerinde yeni parçalar oluşturarak ve düşük talep sırasında kullanılmayan parçaları birleştirerek ağ kaynaklarının etkin kullanımını garanti edebilir.

Dinamik yeniden parçalama, ağ kullanımı arttıkça zor bir çatalla veya önemli bir protokol güncellemesi olmadan blok zincirinin kapasitesini genişletmesine olanak tanır. Verilerin ve işlemlerin parçalar arasında yeniden dağıtılması, blok zincirinin daha tutarlı bir performans sürdürmesine yardımcı olur.

Dinamik yeniden parçalama ayrıca ağın, parça arızaları veya ani talep artışları gibi öngörülemeyen olaylara uyum sağlamasını sağlar.

Genellikle anahtar bileşenlerden birkaçını içeren dinamik yeniden parçalama süreci:

İzleme Sistemi, işlem hacmi, parça kullanımı ve düğüm performansı gibi ağ metriklerini sürekli olarak analiz eder. Karar motoru, ağı ne zaman ve nasıl yeniden parçalara ayıracağını belirlemek için önceden tanımlanmış algoritmalar ve belki de makine öğrenimi teknikleri kullanır. Koordinasyon protokolü, ağdaki tüm düğümlerin yeni parça yapılandırmasını kabul etmesini ve yeniden parçalama sürecini tutarlı bir şekilde yürütmesini sağlar. Parçalar bölündüğünde veya birleştirildiğinde, verileri ve durum bilgilerini güvenli bir şekilde taşır.

İşte olası dinamik yeniden parçalama uygulamalarının kısaltılmış bir özeti:

1. İzleme sistemi, belirli bir parçanın sürekli olarak maksimum kapasitesine yakın işlemler gerçekleştirdiğini tespit eder.

2. Karar motoru, bu parçanın yükü dengelemek için ikiye bölünmesi gerektiğine karar verir.

3. Koordinasyon protokolü yeniden parçalama sürecini başlatır ve tüm düğümlerin yaklaşan değişiklikten haberdar olmasını sağlar.

4. Ağ, yeni parçayı oluşturmak, ilgili verileri taşımak ve yönlendirme bilgilerini güncellemek için dikkatlice düzenlenmiş bir süreç gerçekleştirir.

5. Tamamlandığında, ağ şimdi artan yükü karşılamak için ek bir parçaya sahiptir.

Dinamik yeniden parçalama heyecan verici olanaklar sunarken, aynı zamanda önemli teknik zorluklar da ortaya çıkarır.

Canlı bir blok zinciri ağını güvenli ve verimli bir şekilde yeniden parçalara ayırabilecek bir sistemin uygulanması son derece karmaşıktır ve kapsamlı bir konsensüs ve koordinasyon mekanizmaları gerektirir. Ayrıca, veriler parçalar arasında aktıkça tüm ilgili durum bilgisinin doğru bir şekilde saklanması ve kolayca erişilebilmesi durumu yönetiminde zor bir sorundur.

Dinamik yeniden parçalama, birden fazla parça arasında gerçekleştirilen işlemleri dikkate almak zorundadır, bu da parçaların düzenine bağlı olarak daha karmaşık hale gelebilir. Daha sonra, güvenlik sorunları. Ayrıca, dinamik yeniden parçalama izlemesi ve karar verme prosedürleri ağa ek hesaplama yükü getirir.

Bu zorluklara rağmen, çeşitli blok zinciri girişimleri aktif bir şekilde dinamik yeniden parçalama tekniklerini araştırmaktadır. Örneğin Near Protocol, ana ağında dinamik yeniden parçalara ayırmanın bir türünü başlattı, böylece ağ talebe göre parçaların sayısını değiştirebilir.

Dinamik yeniden parçalama, blok zinciri teknolojisinin gelişmesiyle genel dağıtık uygulama ve hizmetlerin benimsenmesine olanak sağlayan ölçeklenebilir, esnek ağlar inşa etmekte giderek daha önemli hale gelebilir.