BNB Chain'in büyük bloklara giden yolu

BNB Zincirindeki Büyük Blokların Yolu

Solana, Heco ve borsalar tarafından desteklenen diğer halka açık zincirlere benzer şekilde, BNB Chain'in halka açık zinciri BNB Smart Chain (BSC) uzun süredir yüksek performans peşinde koşmaktadır. BSC, 2020'deki lansmanından bu yana, her blok için gaz kapasitesi sınırını 30 milyon olarak belirledi ve 3 saniyelik sabit bir blok aralığı belirledi. Bu parametrelerle BSC, 100'ün üzerinde maksimum TPS (çeşitli işlemlerin bir araya getirildiği TPS) elde etti. Haziran 2021'de BSC'nin blok gaz limiti 60 milyona çıkarılmıştır. Ancak aynı yılın Temmuz ayında, CryptoBlades adlı bir zincir oyunu BSC'de patlayarak günlük işlem hacimlerinin 8 milyonu aşmasına ve ücretlerin hızla yükselmesine neden oldu. BSC'nin verimlilik darboğazının o dönemde hala oldukça belirgin olduğu ortaya çıktı.

(Kaynak: BscScan)

BSC, ağ performansı sorunlarını ele almak için, uzun süre 80-85 milyon civarında sabit kalan her blok için gaz limitini bir kez daha yükseltti. Eylül 2022'de BSC Chain'in blok başına gaz limiti 120 milyona çıkarıldı ve yıl sonunda 2020'nin neredeyse beş katı olan 140 milyona yükseltildi. Daha önce BSC, blok gaz kapasitesi sınırını 300 milyona çıkarmayı planlamıştı, ancak belki de Doğrulayıcı düğümler üzerindeki ağır yük göz önüne alındığında, bu tür süper büyük bloklar için teklif uygulanmadı.

kaynak: YCHARTS

Daha sonra BNB Chain, Layer1 genişlemesinde ısrar etmek yerine modüler/Layer2 yoluna daha fazla odaklanmış görünüyordu. Bu niyet, geçen yılın ikinci yarısında zkBNB'nin lansmanından bu yılın başında GreenField'e kadar giderek daha belirgin hale geldi. Modüler blok zinciri/Katman2'ye olan güçlü ilgisinden dolayı, bu makalenin yazarı, Ethereum Layer2 ile karşılaştırarak Rollup'ın performans darboğazlarını ortaya çıkarmak için opBNB'yi bir araştırma nesnesi olarak kullanacaktır.

BSC'nin yüksek veriminin opBNB'nin DA katmanına yükseltilmesi

Hepimizin bildiği gibi Celestia, modüler blok zincirinin iş akışına göre dört temel bileşeni özetlemiştir: Yürütme Katmanı: Sözleşme kodunu yürütür ve durum geçişlerini tamamlar; Uzlaşma Katmanı: Dolandırıcılık kanıtlarını/geçerlilik kanıtlarını ele alır ve L2 ile L1 arasındaki köprüleme sorunlarını ele alır. Mutabakat Katmanı: İşlem sıralaması konusunda fikir birliğine varır. Veri Kullanılabilirlik Katmanı (DA): Blok zinciri defteriyle ilgili verileri yayınlar ve doğrulayıcıların bu verileri indirmesine olanak tanır.

Bunlar arasında DA katmanı genellikle mutabakat katmanı ile birleştirilir. Örneğin, Optimistic Rollup'ın DA verileri L2 bloklarında bir grup işlem dizisi içerir. L2 tam düğümleri DA verilerini elde ettiklerinde, bu partideki her işlemin sırasını bilirler. (Bu nedenle Ethereum topluluğu, Rollup katmanlanırken DA katmanı ile mutabakat katmanının ilişkili olduğuna inanmaktadır).

Ancak Ethereum Layer2 için DA katmanının (Ethereum) veri çıkışı, Rollup performansını kısıtlayan en büyük darboğaz haline gelmiştir. Bunun nedeni, Ethereum'un mevcut veri veriminin çok düşük olması ve Rollup'ı Ethereum ana ağının L2 tarafından üretilen verileri taşıyamamasını önlemek için TPS'sini mümkün olduğunca bastırmaya zorlamasıdır. Aynı zamanda, düşük veri çıkışı Ethereum ağındaki çok sayıda işlem talimatının beklemede kalmasına neden olarak gaz ücretlerinin aşırı yüksek seviyelere çıkmasına ve Layer2 için veri yayınlama maliyetinin daha da artmasına yol açmaktadır. Son olarak, birçok Layer2 ağı, Celestia gibi Ethereum dışındaki DA katmanlarını benimsemek zorundadır ve suya yakın olan opBNB, veri yayınının darboğaz sorununu çözmek için DA'yı uygulamak üzere doğrudan BSC'nin yüksek verimini kullanmayı seçmiştir. Kolay anlaşılması için, Rollup için DA veri yayınlama yöntemini tanıtalım. Örnek olarak Arbitrum'u ele alırsak, Layer2 sıralayıcısının EOA adresi tarafından kontrol edilen Ethereum zinciri, belirtilen sözleşmeye periyodik olarak İşlemler gönderecektir. Bu talimatın calldata giriş parametrelerine, paketlenmiş işlem verileri yazılır ve ilgili zincir içi olaylar tetiklenerek sözleşme günlüklerinde kalıcı bir kayıt bırakılır.

Bu sayede Layer2'nin işlem verileri Ethereum bloklarında uzun süre saklanır. L2 düğümlerini çalıştırabilen kişiler ilgili kayıtları indirebilir ve ilgili verileri ayrıştırabilir, ancak Ethereum düğümlerinin kendileri bu L2 işlemlerini gerçekleştirmez. L2'nin işlem verilerini yalnızca Ethereum bloklarında depoladığını ve depolama maliyetlerine neden olduğunu, işlemlerin yürütülmesinin hesaplama maliyetlerinin ise L2 düğümlerinin kendileri tarafından karşılandığını görmek kolaydır. Yukarıda bahsedilen Arbitrum'un DA'sının uygulama yöntemidir, Optimism ise sıralayıcı tarafından kontrol edilen bir EOA adresini kullanarak belirtilen başka bir EOA adresine aktarım yapar ve ek verilerde yeni bir Layer2 işlem verisi grubu taşır. OP Yığınını kullanan opBNB'ye gelince, DA veri yayınlama yöntemi temelde Optimism ile aynıdır.

DA katmanının iş hacminin Rollup'ın birim zamanda yayınlayabileceği veri boyutunu sınırlayacağı ve dolayısıyla TPS'yi sınırlayacağı açıktır. EIP1559'dan sonra her ETH bloğunun gaz kapasitesinin 30 milyonda sabitlendiği ve birleştirme sonrası blok süresinin yaklaşık 12 saniye olduğu düşünüldüğünde, Ethereum saniyede en fazla 2,5 milyon gaz işleyebilmektedir. Çoğu zaman, calldata'daki bayt başına L2 işlem verilerini barındırarak tüketilen gaz 16'dır, bu nedenle Ethereum saniyede yalnızca 150 KB'lık maksimum calldata boyutunu kaldırabilir. Buna karşılık, BSC'nin saniyede işlenen maksimum ortalama calldata boyutu yaklaşık 2910 KB'dir ve bu da Ethereum'un 18,6 katıdır. DA katmanları olarak ikisi arasındaki fark açıktır.

Özetlemek gerekirse, Ethereum saniyede yaklaşık 150 KB L2 işlem verisi taşıyabilir. EIP 4844'ün lansmanından sonra bile bu rakam çok fazla değişmeyecek, sadece DA ücreti azalacak. Peki saniyede yaklaşık 150KB'a kaç işlem verisi dahil edilebilir? Burada Rollup'ın veri sıkıştırma oranını açıklamamız gerekiyor. Vitalik 2021'de aşırı iyimser davranarak Optimistic Rollup'ın işlem veri boyutunu orijinal boyutun %11'ine kadar sıkıştırabileceğini tahmin etti. Örneğin, başlangıçta 112 baytlık bir calldata boyutunu kaplayan temel bir ETH aktarımı, Optimistic Rollup ile 12 bayta, ERC-20 aktarımları 16 bayta ve Uniswap üzerindeki Swap işlemleri 14 bayta sıkıştırılabilir. Tahminine göre, Ethereum saniyede yaklaşık 10.000 L2 işlemi kaydedebilir (çeşitli türler birbirine karıştırılarak). Ancak Optimism ekibi tarafından 2022 yılında açıklanan verilere göre, gerçek veri sıkıştırma oranı en fazla %37'ye ulaşabilmektedir ki bu oran Vitalik'in tahmininden 3,5 kat daha düşüktür.

(Vitalik'in Rollup ölçeklenebilirlik etkisi tahmini gerçek koşullardan önemli ölçüde sapmaktadır)

(Optimism tarafından açıklanan çeşitli sıkıştırma algoritmalarıyla elde edilen gerçek sıkıştırma oranları)

O halde makul bir sayı verelim: Ethereum verim sınırına ulaşsa bile, tüm Optimistic Rollup'ların maksimum TPS'si 2000'in biraz üzerindedir. Başka bir deyişle, Ethereum blokları tamamen Arbitrum, Optimism, Base ve Boba arasında dağıtılanlar gibi Optimistic Rollup'lar tarafından yayınlanan verileri taşımak için kullanılsaydı, bu Optimistic Rollup'ların birleşik TPS'si en verimli sıkıştırma algoritmaları altında bile 3000'e ulaşmazdı. Buna ek olarak, EIP1559'dan sonra her bir bloğun gaz kapasitesinin maksimum değerin ortalama sadece %50'si olduğunu, dolayısıyla yukarıdaki rakamın yarıya indirilmesi gerektiğini göz önünde bulundurmalıyız. EIP4844'ün piyasaya sürülmesinden sonra, verilerin yayınlanması için işlem ücretleri önemli ölçüde azalacak olsa da, Ethereum'un maksimum blok boyutu çok fazla değişmeyecek (çok fazla değişiklik ETH ana zincirinin güvenliğini etkileyeceğinden), bu nedenle yukarıdaki tahmini değer çok fazla ilerlemeyecektir.

Arbiscan ve Etherscan'dan alınan verilere göre, Arbitrum'daki bir işlem grubu 1115 işlem içeriyor ve Ethereum'da 1,81 milyon gaz tüketiyor. Ekstrapolasyonla, DA katmanı her blokta doldurulursa, Arbitrum'un teorik TPS limiti yaklaşık 1500'dür. Elbette, L1 bloklarının yeniden düzenlenmesi konusu göz önüne alındığında, Arbitrum her Ethereum bloğunda işlem gruplarını yayınlayamaz, bu nedenle yukarıdaki sayılar şu anda yalnızca teoriktir. Ayrıca, EIP 4337 ile ilgili akıllı cüzdanların yaygınlaşmasıyla DA sorunu daha da ciddi hale gelecektir. Çünkü EIP 4337 desteğiyle, kullanıcıların kimliklerini doğrulama şekli, parmak izlerinin veya irislerin ikili verilerini yüklemek gibi özelleştirilebilir ve bu da düzenli işlemlerin kapladığı veri boyutunu daha da artıracaktır. Bu nedenle, Ethereum'un düşük veri çıkışı, Toplama verimliliğini sınırlayan en büyük darboğazdır ve bu sorun uzun süre düzgün bir şekilde çözülemeyebilir. Öte yandan, BSC genel zincirinin BNB Zincirinde, saniyede işlenen maksimum ortalama calldata boyutu yaklaşık 2910 KB'dir ve bu da Ethereum'un 18,6 katıdır. Başka bir deyişle, yürütme katmanı ayak uydurabildiği sürece, BNB Zinciri ekosistemindeki Katman2'nin teorik TPS üst sınırı ARB veya OP'nin yaklaşık 18 katına ulaşabilir. Bu sayı, mevcut BNB Zincirinin 140 milyonluk maksimum blok gaz kapasitesi ve 3 saniyelik blok süresi temel alınarak hesaplanmıştır.

Başka bir deyişle, BNB Chain ekosistemindeki tüm Rollup'ların mevcut toplam TPS limiti Ethereum'un 18,6 katıdır (ZKRollup dikkate alındığında bile). Bu açıdan bakıldığında, bu kadar çok Layer2 projesinin veri yayınlamak için neden Ethereum zinciri altındaki DA katmanını kullandığını anlamak kolaydır, çünkü aradaki fark oldukça belirgindir. Ancak mesele bu kadar basit değildir. Veri çıkışı sorununun yanı sıra, Katman1'in kararlılığı da Katman2'yi etkileyebilir. Örneğin, çoğu Rollup, Layer1 bloğunun yeniden düzenlenmesi olasılığını göz önünde bulundurarak, Ethereum'a bir grup işlem yayınlamadan önce genellikle birkaç dakika bekler. Bir Katman1 bloğu yeniden düzenlenirse, bu durum Katman2'nin blok zinciri defterini etkileyecektir. Bu nedenle, sıralayıcı bir L2 işlem grubunun her yayınlanmasından sonra birkaç yeni Layer1 bloğunun yayınlanmasını bekleyecek ve bir sonraki L2 işlem grubunu yayınlamadan önce blok geri alma olasılığını önemli ölçüde azaltacaktır. Bu aslında L2 bloklarının nihayet onaylanma süresini geciktirerek büyük işlemlerin onaylanma hızını düşürür (büyük işlemler güvenliği sağlamak için geri döndürülemez sonuçlar gerektirir). Özetle, L2'de gerçekleşen işlemler ancak DA katmanı bloklarında yayınlandıktan ve DA katmanı belirli sayıda yeni blok ürettikten sonra geri döndürülemez hale gelir. Bu, Toplama performansını sınırlayan önemli bir nedendir. Bununla birlikte, Ethereum yavaş bir blok oluşturma hızına sahiptir ve bir bloğun üretilmesi 12 saniye sürer. Rollup'ın her 15 blokta bir L2 işlem grubu yayınladığını varsayarsak, farklı gruplar arasında 3 dakikalık bir aralık olacaktır ve her grup yayınlandıktan sonra, geri döndürülemez hale gelmeden önce (itiraz edilmedikleri varsayılırsa) birden fazla Katman1 bloğunun oluşturulmasını beklemesi gerekir. Açıkçası, Ethereum'un Layer2'sinde işlemlerin başlatılmasından geri döndürülemez hale gelmesine kadar geçen süre oldukça uzundur ve bu da yavaş ödeme hızına neden olur; oysa BNB Chain'de bir blok üretmek yalnızca 3 saniye sürer ve bloklar yalnızca 45 saniye içinde geri döndürülemez hale gelir (15 yeni blok üretmek için gereken süre). Mevcut parametrelere dayanarak, aynı sayıda L2 işlemi varsayıldığında ve L1 bloklarının geri döndürülemezliği göz önüne alındığında, opBNB'nin birim zamanda işlem verilerini yayınlama sayısı Arbitrum'un 8,53 katına kadar çıkabilir (ilki için her 45 saniyede bir ve ikincisi için her 6,4 dakikada bir). Açıkça görüldüğü üzere, opBNB üzerindeki büyük işlemlerin mutabakat hızı Ethereum'un Layer2'sinden çok daha hızlıdır. Ayrıca, opBNB tarafından her seferinde yayınlanan maksimum veri boyutu Ethereum'un Layer2'sinin 4,66 katına ulaşabilmektedir (ilkinin L1 blok gaz limiti 140 milyon iken ikincisinin 30 milyondur). 8.53 * 4.66 = 39.74. Bu, pratik uygulamada TPS sınırı açısından opBNB ve Arbitrum arasındaki boşluğu temsil eder (şu anda, güvenlik nedenleriyle, ARB TPS'yi aktif olarak azaltıyor gibi görünmektedir, ancak teorik olarak, TPS artırılacak olsaydı, opBNB'ye kıyasla hala birçok kez daha düşük olacaktır).

(Arbitrum'un sıralayıcısı her 6-7 dakikada bir işlem grubu yayınlar)

(opBNB'nin sıralayıcısı her 1-2 dakikada bir işlem grubu yayınlar ve en hızlısı sadece 45 saniye sürer). Elbette göz önünde bulundurulması gereken bir diğer önemli husus da DA katmanındaki gaz ücretleridir. L2'nin bir işlem yığınını her yayınlayışında, calldata boyutuyla ilgisi olmayan 21.000 gazlık sabit bir maliyet vardır ve bu bir masraftır. DA katmanı/L1 için gaz ücretleri yüksekse ve bu da L2'de bir işlem grubu yayınlamanın sabit maliyetinin yüksek kalmasına neden oluyorsa, sıralayıcı işlem gruplarını yayınlama sıklığını azaltacaktır. Ayrıca, L2 ücretlerinin bileşenleri göz önünde bulundurulduğunda, yürütme katmanının maliyeti çok düşüktür ve genellikle göz ardı edilebilir, yalnızca DA maliyetlerinin işlem ücretleri üzerindeki etkisine odaklanılır. Özetle, aynı boyutta calldata yayınlamak Ethereum ve BNB Chain'de aynı miktarda gaz tüketirken, Ethereum tarafından talep edilen gaz fiyatı BNB Chain'inkinden yaklaşık 10 ila onlarca kat daha yüksektir. L2 işlem ücretlerine çevrildiğinde, Ethereum Layer2'deki mevcut kullanıcı işlem ücretleri de opBNB'dekilerden yaklaşık 10 ila onlarca kat daha yüksektir. Genel olarak, Ethereum üzerinde opBNB ve Optimistic Rollup arasındaki farklar oldukça belirgindir.

(İyimserlikte 150.000 gaz tüketen bir işlem 0,21 dolara mal olur)

(opBNB'de 130.000 gaz tüketen bir işlemin maliyeti 0,004$'dır) Bununla birlikte, DA katmanının veri verimini artırmak, Katman2 sisteminin genel verimini artırabilirken, yine de bireysel Toplama işlemlerinin performans iyileştirmesi üzerinde sınırlı bir etkiye sahiptir. Bunun nedeni, yürütme katmanının genellikle işlemleri yeterince hızlı işlememesidir. DA katmanının sınırlamaları göz ardı edilebilse bile, yürütme katmanı Rollup performansını etkileyen bir sonraki darboğaz haline gelir. Katman2 yürütme katmanının yürütme hızı yavaşsa, işlem talebinin taşması diğer Katman2'lere yayılacak ve sonuçta likidite parçalanmasına neden olacaktır. Bu nedenle, DA katmanının üzerinde bir başka eşik görevi gören yürütme katmanının performansının iyileştirilmesi de çok önemlidir.

opBNB'nin Yürütme Katmanındaki Artışı: Önbellek Optimizasyonu

Çoğu kişi blok zinciri yürütme katmanlarının performans darboğazlarını tartıştığında, kaçınılmaz olarak iki önemli darboğazdan bahseder: EVM'nin CPU'yu tam olarak kullanamayan tek iş parçacıklı seri yürütmesi ve Ethereum tarafından benimsenen Merkle Patricia Trie'nin verimsiz veri araması. Temelde, yürütme katmanı için ölçeklendirme stratejileri, CPU kaynaklarının daha verimli kullanılması ve CPU'nun verilere olabildiğince hızlı erişebilmesinin sağlanması etrafında döner.

Seri EVM yürütme ve Merkle Patricia Trie için optimizasyon çözümleri genellikle karmaşık ve uygulaması zordur, daha uygun maliyetli çabalar ise önbellek optimizasyonuna odaklanma eğilimindedir. Aslında, önbellek optimizasyonu bizi geleneksel Web2 ve hatta ders kitabı bağlamlarında sıkça tartışılan noktalara geri götürür.

Tipik olarak, CPU'nun bellekten veri alma hızı, diskten veri almaktan yüzlerce kat daha hızlıdır. Örneğin, bellekten veri almak yalnızca 0,1 saniye sürerken, diskten veri almak 10 saniye sürebilir. Bu nedenle, disk okuma ve yazmalarından kaynaklanan ek yükün azaltılması, yani önbellek optimizasyonu, blok zinciri yürütme katmanını optimize etmenin önemli bir yönü haline gelir.

Ethereum'da ve diğer halka açık zincirlerin çoğunda, zincir üzerindeki adres durumlarını kaydeden veritabanı tamamen diskte saklanırken, World State trie denilen şey yalnızca bu veritabanının bir dizini veya veri araması için kullanılan bir dizindir. EVM bir sözleşmeyi her yürüttüğünde, ilgili adres durumlarına erişmesi gerekir. Disk tabanlı veritabanından verilerin tek tek getirilmesi işlemin yürütülmesini önemli ölçüde yavaşlatacaktır. Bu nedenle, veritabanı/disk dışında bir önbellek oluşturmak hızlanmak için gerekli bir araçtır.

opBNB, BNB Chain tarafından kullanılan önbellek optimizasyon çözümünü doğrudan benimser. OpBNB'nin ortağı NodeReal tarafından açıklanan bilgilere göre, en eski BSC zinciri EVM ile durumu depolayan LevelDB veritabanı arasında üç katmanlı önbellek oluşturmuştur. Tasarım konsepti, daha yüksek erişim sıklığına sahip verilerin önbellekte depolandığı geleneksel üç seviyeli önbelleklere benzer. Bu, CPU'nun önce önbellekte gerekli verileri aramasını sağlar. Önbellek isabet oranı yeterince yüksekse, CPU'nun veri getirmek için diske aşırı güvenmesi gerekmez ve bu da genel yürütme hızında önemli bir iyileşme sağlar.

Daha sonra NodeReal bunun üzerine, EVM'nin gelecekte işlemesi gereken verileri veritabanından önceden okumak ve önbellekte saklamak için kullanılmayan CPU çekirdeklerinden yararlanan bir özellik ekledi. Bu özellik "durum ön yüklemesi" olarak adlandırılır.

Durum ön yüklemesinin prensibi basittir: blok zinciri düğümlerinin CPU'ları çok çekirdeklidir, EVM ise tek iş parçacıklı seri yürütme modunda çalışır, yalnızca bir CPU çekirdeği kullanır ve diğer CPU çekirdeklerini atıl bırakır. Bunu ele almak için, EVM tarafından kullanılmayan CPU çekirdekleri, EVM'nin henüz işlenmemiş işlem dizisinden ihtiyaç duyacağı verileri tahmin ederek görevlere yardımcı olabilir. EVM dışındaki bu CPU çekirdekleri daha sonra EVM'nin ihtiyaç duyacağı verileri veritabanından alarak EVM'nin veri alma yükünü azaltmasına ve böylece yürütmeyi hızlandırmasına yardımcı olacaktır.

Önbellek optimizasyonu ve yeterli donanım yapılandırmalarıyla opBNB, düğümünün yürütme katmanının performansını EVM'nin sınırına yaklaştırarak saniyede 100 milyona kadar gaz işlemiştir. Bu 100 milyon gaz, önde gelen bir kamu zincirinden alınan deneysel test verilerinin de gösterdiği gibi, değiştirilmemiş EVM'nin performans tavanıdır.

Kısaca ifade etmek gerekirse, opBNB saniyede 4761 basit transfer, saniyede 15003000 ERC20 token transferi ve blok zinciri kaşiflerinde gözlemlenen işlem verilerine dayanarak saniyede yaklaşık 5001000 SWAP işlemi gerçekleştirebilir. Mevcut parametreler karşılaştırıldığında, opBNB'nin TPS limiti Ethereum'un 40 katı, BNB Chain'in 2 katından fazla ve Optimism'in 6 katından fazladır.

Elbette, Ethereum Layer2 çözümleri için, DA katmanının kendisinin ciddi sınırlamaları nedeniyle, DA katmanı blok oluşturma süresi ve kararlılığı gibi faktörler göz önünde bulundurulduğunda, performans, yürütme katmanının performansına bağlı olarak önemli ölçüde azalır.

OpBNB gibi yüksek verimli bir DA katmanına sahip BNB Zinciri için, özellikle BNB Zincirinin bu türden birden fazla ölçeklendirme projesine ev sahipliği yapabileceği düşünüldüğünde, ölçeklendirmenin iki katına çıkma etkisi değerlidir. BNB Chain'in opBNB liderliğindeki Layer2 çözümlerini halihazırda stratejik planlarına dahil ettiği ve Ethereum Layer2 ekosistemiyle rekabet etmek veya işbirliği yapmak amacıyla ZK kanıtlarını opBNB'ye dahil etmek ve GreenField gibi tamamlayıcı altyapılarla yüksek kullanılabilirlikli DA katmanları sağlamak da dahil olmak üzere daha fazla modüler blok zinciri projesine katılmaya devam edeceği öngörülebilir.

Katmanlı ölçeklendirmenin trend haline geldiği bu dönemde, diğer halka açık zincirlerin de kendi Layer2 projelerini desteklemek için acele edip etmeyeceğini göreceğiz, ancak şüphesiz, modüler blok zinciri altyapısına doğru paradigma değişimi halihazırda gerçekleşiyor.

Sorumluluk Reddi：

1. Bu makale[极客 Web3] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazara aittir[Faust, 极客web3]. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.