By 
Ethereum (ETH) kurucu ortağı Vitalik Buterin, Ethereum’un işlevselliğini artırırken karmaşıklığını azaltmanın mümkün olduğunu söyledi. Buterin’in bu açıklaması geliştiriciler son zamanlarda Ethereum’un karmaşıklığından şikayet ederken geldi.
Buterin, son blog yazısında Ethereum’un kritik noktalarını inceledi. Geliştirici ekibin “daha karmaşık bir şey ile daha basit bir şey arasında ödünleşime sahip olduğunu” söyleyen Buterin, bazen basit olanı seçtiklerini, ancak daha karmaşık bir şeye ulaştıklarını söyledi.
Buterin örneğin Gasper proof-of-stake (PoS) versiyonunun karmaşık olsa da son derece güçlü bir sistem olduğunu söyledi. Buna karşılık PoS’un iyi adaylar olabilecek çok daha basit ve daha zayıf versiyonları var, ancak bunlar Gasper’ın avantajlarını sunmuyor.
Buterin, “Gasper’ın bu algoritmalardan daha karmaşık olması, onlardan çok daha fazlasını başarmaya çalışmasıdır. Ancak başlangıçta daha mütevazı olsaydık, önce daha sınırlı hedeflere ulaşmaya odaklanabilirdik.”
Buterin iki vizyon arasında mücadele verdiğini açıkladı: biri güvenlik ve basitliğe değer vermek (Bitcoin (BTC) gibi) ve diğeri Ethereum’u gelişmiş uygulamalar oluşturmak için yüksek performanslı ve işlevsel bir platform haline getirmek.
“Benim hayalim her ikisine de aynı anda ulaşmak” diyen Buterin, bu hedefe ulaşmanın uzun ve meşakkatli bir süreç olacağını da sözlerine ekledi. Ancak karmaşıklığı azaltmanın mümkün olduğunu kaydetti.
Buterin, “Bugün değiştiremeyeceğimiz çok şey var, ancak yapabileceğimiz de çok şey var ve hem işlevsellik hem de basitlik geliştirilebili” dedi.
Buterin ayrıca bazı Ethereum İyileştirme Önerilerinin (EIP’ler) karmaşıklığı azaltmanın mümkün olduğunu kanıtladığını iddia etti. Örneğin EIP-150’nin çağrı yığını derinlik sınırını artık uygun hale getirerek sözleşme geliştiricileri için güvenlik endişelerini azaltmayı başardığını söyledi.
Buterin’in ayrıntılı blog yazısının bazı geliştiricilerin Ethereum’un artan karmaşıklığı konusundaki endişelerine bir yanıt olduğu görülüyor.
Ethereum’da yazılım geliştiricisi olan Péter Szilágyi, kısa bir süre önce karmaşıklığın Ethereum tarihinde hiçbir zaman düşmediğini söyledi. Szilágyi, karmaşıklığın çok fazla insan yüklemek, kapasiteyi kaybetmek ve daha büyük bir yüke yol açmak gibi peş peşe gelen sorunlara yol açtığı konusunda uyardı.
As with scalability, complexity also keeps trickling unseen up to the breaking point. At that time, it's already past the point of no return.
— Péter Szilágyi (karalabe.eth) (@peter_szilagyi) March 18, 2022
Complexity also has the nasty effect of causing cascading failures. Overload people too much, lose capacity, leading to even larger load.
Szilágyi, “Merge’e yaklaşsak da Ethereum’un engelsiz bir yöne gitmediğini belirtmeliyim. Kabaca sonuçlara ulaşıyor, ancak yarınlar yokmuş gibi karmaşıklığı artırıyor” dedi.
Szilágyi’ye göre artan karmaşıklığın esas nedeni araştırma ve geliştirme ekipleri arasındaki iletişim kopukluğudur. Araştırma ekibinin “sadece” zekice, bağımsız fikirler düşünmesi gerekirken, geliştirme ekibinin ise alanın boyutsallığını genişletirken şimdiye kadar ortaya konan her bir fikri değerlendirmesi gerektiğini söyledi.
There have been engineering attempts to reduce the complexity (module split in Erigon, responsibility split in The Merge). Yet there was never an attempt to reduce the protocol complexity.
— Péter Szilágyi (karalabe.eth) (@peter_szilagyi) March 18, 2022
We are already past the point of anyone having a full picture of the system. This is bad.
Bu arada, Bitcoin için akıllı sözleşmelerin yürütülmesine imkan tanıyan bir katman 1 blok zinciri olan açık kaynaklı akıllı sözleşme platformu Stacks‘ın kurucu ortağı Muneeb Ali, Ethereum’un gelişmiş uygulamaları barındırabilen basit, güvenli bir blockchain oluşturma vizyonu yerine iki katmanı hedefleyebileceğini öne sürdü.
“do we have fewer features and be more Bitcoin-like, or more features and be more developer-friendly?”
— muneeb.btc (@muneeb) March 30, 2022
Bitcoin = simple, money layer
Stacks = dev-friendly contracts layer
The answer to this tension is two layers. https://t.co/aqNdVL8CcA
Comments