Ethereum çekirdek yönetişimi açıklandı

Ethereum Vakfı'ndan Nixo Rokish'in ETHBoulder'da yaptığı, Ethereum'un çekirdek protokol yönetişimini, sert çatallanmaların nasıl koordine edildiğini, Ethereum'u kimin kontrol ettiğine dair yaygın yanlış bilinenleri ve yönetişim sürecine nasıl katılınacağını açıklayan bir sunum.

Bu döküm, EthBoulder tarafından yayımlanan orijinal video dökümünün (opens in a new tab) erişilebilir bir kopyasıdır. Okunabilirliği artırmak için üzerinde ufak düzenlemeler yapılmıştır.

Giriş (0:12)

Gelen altı arkadaşımın hepsine teşekkürler. Pekala. Bugün sizinle Ethereum çekirdek yönetişimi hakkında konuşacağım. Adım Nixo. EF'deki (Ethereum Vakfı) protokol destek ekibini yönetiyorum. Tüm görevlerimiz arasında, görevlerimizden biri de yönetişim sürecini bu işlere katılan herkes için daha açık ve gezinmesi daha kolay hale getirmektir, çünkü Ethereum sadece çekirdek geliştiricilerinden çok daha fazlasını içerir.

İşte konuşmanın bir özeti. Çekirdek yönetişimin ne olduğu hakkında konuşacağız. Yanlış bilinenler ve Ethereum yönetişiminin şu anda nasıl işlediği hakkında konuşacağız. Diğer merkeziyetsiz yönetişim sistemleriyle nasıl karşılaştırıldığına, geliştiricilerin neden umursaması gerektiğine ve katılım için eyleme geçirilebilir yollara değineceğiz.

Peki, çekirdek protokol yönetişimi nedir? Ben bir düğüm çalıştırıyorum. Bunun anlamı, evimde Ethereum yazılımını çalıştırdığım bir donanım parçasına, bir bilgisayara sahip olmamdır. Bu Ethereum yazılımını kurduğumda, o yazılımı çalıştıracak istemcileri seçmem gerekiyordu. Ethereum, istemci çeşitliliği için birden fazla istemciye sahip olması bakımından oldukça benzersizdir. Bunun amacı, bir istemci çökerse, bir istemcide bir hata olursa, tüm ağın çökmemesidir. Başka istemcilere sahip olan başka blokzincirler de var. Ancak Ethereum, bizi hatalara karşı gerçekten koruyacak şekilde kurulmuş tek blokzincirdir. Yani, örneğin Solana'ya bakarsanız, Solana'nın başka bir istemcisi var, sanırım adı GTO gibi bir şey, ancak yalnızca %20-21 oranında benimsenmiş durumda. Bu yüzden, çoğunluk istemcisi çökerse, zincir de çöker. Ve diğer ağların çöktüğünü gördük. İşte bu yüzden Ethereum en dayanıklı, en güvenli blokzincirdir.

Bu durumda soru, bu kadar çok farklı istemciyle koordine olmanız gerektiğinde Ethereum'a değişiklikleri nasıl dahil edeceğinizdir. İlk olarak sert çatallanma ile yumuşak çatallanma arasındaki farkı belirteceğiz. Yumuşak çatallanma, sert çatallanmanın gerektirdiği koordinasyonu gerektirmez. Ethereum temel olarak sert çatallanmalarla çalışır. Yani sert çatallanma, temelde tüm istemcilerin Ethereum'un yeni bir sürümünü oluşturması ve önceden yapılandırılmış bir zamanda Ethereum'un bu yeni sürümünü başlatmaya karar vermesidir. Hâlâ Ethereum'dur ancak yeni özelliklere sahiptir. Farklı özellikleri vardır. Ve evde düğüm çalıştıran benim gibi tüm düğüm operatörleri veya profesyonel operatörler Ethereum'un bu yeni sürümünü kabul etmek zorundadır. Düğümlerini yükseltmeleri veya o yeni yazılımı içerecek şekilde düğümlerini güncellemeleri gerekir.

Peki bu sert çatallanmalara hangi özelliklerin gireceğine nasıl karar veriyorlar? Zamanlarını ve kaynaklarını tahsis etmek için öncelikler üzerinde anlaşmaları gerekir çünkü oraya tahsis edecekleri sınırlı zamanları ve kaynakları vardır. Güvenlik açıkları veya güvenlik yamaları, kullanıcı deneyimi (UX) gibi şeylere öncelik verirler — bizimle rekabet eden başka bir blokzincir varsa, o diğer blokzincirlerle rekabet edebilir hale gelmemiz gerekir. Bu yüzden baktıkları şeylerden biri, eklenecek herhangi bir özelliğin gelecekteki potansiyel yol haritası öğeleriyle ileriye dönük uyumlu olması gerektiğidir.

Geçen yıl gerçekten tartışmalı bir olay yaşandı. Duymuş olabilirsiniz. Adı EOF'ti. Yani EVM Nesne Formatı (EOF). Bu, Fusaka sert çatallanmasına — Pectra, Fusaka, sanırım ikisine de — girmesi planlanan bir dizi özellikti ancak bölündü. Ve bu çatallanmadan çıkarılmasının birçok tetikleyicisinden biri, Vitalik'in Ethereum'un RISC-V'yi benimseme potansiyeli hakkında bir gönderi paylaşmasıydı. Bunu okuyan birçok kişi baktı ve şöyle dedi: Tamam, eğer RISC-V'yi benimsersek EOF'te baktığımız özellikler RISC-V ile yerleşik olarak geliyor. O halde neden protokole bu karmaşıklığı ekleyelim? Neden tüm bu istemci geliştirici kaynaklarını bu işe ayıralım? Sonunda RISC-V'ye geçersek bu anlamsız bir konu olurdu.

Yani bu, EOF konusunda bardağı taşıran son damla oldu ve sonunda çatallanmadan çıkarıldı. Dikkate almaları gereken bir diğer şey de, bu istemciler altı farklı dilde yazıldığı için altı farklı dilde yazılması ve titizlikle test edilmesi gerektiğidir. Bu yüzden üzerinde çalışmaları gereken gerçekten büyük bir test matrisi var. Ve bu nedenle, her küçük tasarım seçimi, anlaşmazlıkları çözecek hiçbir otorite olmadan tartışmaya tabi tutulur. Bu da şu soruyu gündeme getiriyor: Kim karar veriyor? Ki bu da yönetişimin can alıcı noktasıdır.

Yanlış Bilinenler (5:23)

Bu bizi yanlış bilinenlere getiriyor ve bunlardan bazılarını ele alacağız. Birincisi, Ethereum protokolüne neyin gireceğine Vitalik'in karar verdiğidir. Bunun bir uzantısı, EF'nin her şeyi kontrol ettiğidir. Ve üçüncüsü, her şeyin kapalı kapılar ardında yapılan anlaşmalar olduğu — bu kararları içeridekilerin, eski kurtların (OG'lerin) aldığıdır.

Yani birincisi: Vitalik karar verir. Vitalik tarafından yazılan ve durgunlaşmış Ethereum İyileştirme Teklifleri'nin (EIP) bir alt kümesini seçtim. Bunun anlamı şudur: Vitalik oturdu, bir teklif yazdı ve bu şeylerin Ethereum'a girmesini istiyorum dedi ve kimse aynı fikirde olmadı — bu şeyler öylece duruyor. Bunları protokole dahil edemedi. Yani önerdiği her şey otomatik olarak dahil edilmiyor.

Bunun bir uzantısı da Ethereum Vakfı'nın her şeyi kontrol ettiğidir. Bununla çeliştiğini düşündüğüm belirli bir zaman örneği seçeceğim. 2024'te gaz limiti hakkında çok fazla konuşma oldu. Ve bunun nedeni, 2022'de Birleşme sırasında gaz limitini 30 milyona çıkarmamızdı. Bu, bir blokta izin verilen maksimum hesaplamadır. Ve sonra bir süre buna pek dokunmadık çünkü insanların "İşte bu yüzden Ethereum'a geçmiyorum" veya "Bu, Ethereum'daki mevcut kullanım durumumu kısıtlıyor" dediği bir darboğaz değildi.

Ve 2023'ün sonlarında, 2024'ün başlarında, Solana'nın geldiğine dair bir anlatı vardı. Ethereum'un tahtını sallayacaktı. Bu yüzden insanlar Ethereum'un hızlanmak için ne yapabileceğini düşünüyordu. Ve bunlardan biri de bu gaz metriğini pompalayalım fikriydi. Ve o zamanlar EF ve istemci geliştiricileri, "Endişelenecek başka şeylerimiz var. Yine de teşekkürler." gibi bir tavır içindeydiler. Ancak bu iki kişi, Eric Connor ve Mariano Conti, gelip "Hayır, gaz limitini yükseltiyoruz." dediler. Gaz limiti, doğrulayıcı kontrollü bir parametredir. Bu yüzden doğrulayıcılarla, profesyonel operatörlerle konuşmaya başlayıp "Hey, gaz limitinizi yükseltin." diyebildiler.

Ve bir noktada, EF ve istemcilerin "Oh, buna dikkat etmeliyiz. Yaptıkları şeyin güvenli olduğundan ve bunu yükselttikleri değerin ağ için güvenli bir şey olacağından emin olmalıyız." diyecekleri kadar yeterli benimsenme oldu. Bu yüzden kaynaklarını yeniden tahsis etmek zorunda kaldılar. Nethermind bu test çerçevesini ortaya çıkardı. EF, Berlin'de bir sürü çalışma yaptı. Tüm istemci geliştiricileri bunu kıyaslıyordu. Ve bunu seviyorum çünkü neyin önceliklendirileceğine karar verme konusunda EF'yi mecbur bıraktı.

Ve burada ekran görüntüsünü aldığım bu aptalca tweet'i seviyorum çünkü rastgele bir haber kaynağının Eric Connor ve Mariano Conti'ye çekirdek geliştirici demesi gibi bir şey. Onlar çekirdek geliştirici değiller. Eric Connor bir staker ve topluluk üyesiydi. Mariano Conti eski bir MakerDAO uygulama geliştiricisiydi. Ancak onlara sadece çekirdek geliştirici dendi çünkü Ethereum geliştirmesi geleneksel yazılımın nasıl çalıştığı dünyasının gerçekten dışındadır ve bu yüzden temel bir parametrenin değiştirildiğini gördüler ve "Oh, bunlar çekirdek geliştiriciler olmalı." dediler. Değillerdi. Yani bu, topluluk üyelerinin gelip bu değişikliği görmek istiyoruz demesinin ve bunu gerçekleştirmesinin sadece bir örneğidir.

Her şey kapalı kapılar ardında yapılan anlaşmalar, içeridekiler, eski kurtlar (OG'ler) — bunun neden yanlış bilinen bir şey olduğunu biraz daha iyi anlıyorum çünkü temelde bu yönetişim çağrılarına geliyorsunuz, bu yönetişim çağrılarında yüz kişi var. Hepsi olup bitenler konusunda çok rahat görünüyor. Siz ise kaybolmuşsunuz. Bu kararların nasıl alındığına dair hiçbir fikriniz yok. "Konuşma sırası bana geldi mi?" diyorsunuz. Ve sanki insanlar bu kararları almak için aynı 10 kişiyi dinliyormuş gibi hissettiriyor.

Meritokrasi ve katılım istatistikleri (10:18)

Ancak gerçek şu ki, Ethereum geliştirmesi çoğu yazılım geliştirmesinde gördüğümden çok daha fazla bir meritokrasidir. Bu ekran görüntüsündeki tüm bu insanlar — bu, ekran görüntüsünü almaya karar verdiğim rastgele bir ACD çağrısındaki üç kişiden biri — bu insanların hiçbiri burada olmak için atanmadı. Herkes sadece bir şekilde ortaya çıkan insanlar. Onlar bu protokolle çok zaman geçirmiş geliştiriciler. İnsanların bu alanda sürekli olarak iyi kararlar veren yetenekli geliştiriciler olarak kabul ettiği kişilerdir ve buradaki hiç kimse burada olmak için atanmamıştır.

Ben EF'ye sadece bir yıldan biraz daha uzun bir süre önce katıldım. Bu istatistikleri aldım. Sadece Mart 2025'e kadar gidiyorlar. Yani bir yıldan az. Ortalama Tüm Çekirdek Geliştirici (All Core Dev - ACD) katılımcıları — yani yönetişim çağrıları — 98'dir. Yani bu çağrılarda ortalama 98 kişi var. O zamandan beri bir çağrıdaki maksimum katılımcı sayısı 153'tü. Sanırım o gün Pectra ana ağ tarihine karar veriyorduk. Ve sadece geçen yılki toplam benzersiz katılımcı sayısı 567. Bu metriği gerçekten seviyorum çünkü bu çağrılara her seferinde aynı 100 kişinin gitmediğini gösteriyor. Bu uygulama geliştiricileri, araştırmacılar, birisi tartışılan bir özellik hakkında bir şeyler duyuyor, buna karşı olduklarını veya desteklediklerini dile getirmek için ortaya çıkıyorlar ve sonra başka bir çağrıya gelmiyorlar.

Yönetişim süreci nasıl işler (11:52)

Bu biraz sıkıcı bir slayt ama üzerinden geçmenin önemli olduğunu düşünüyorum — Ethereum'un yönetişimi şu anda bu şekilde işliyor. Yani bu çatallanmalardan biri tartışılırken olan ilk şey, insanların bu ayrılan zaman aralığında ana tekliflerini sunabilmeleridir. Ana teklif, insanların bu çatallanma etrafında toplanmasını istediğimiz ana özelliktir. Bu bir topluluk üyesi, bir araştırmacı, bir çekirdek geliştirici olabilir — gerçekten bu ana tekliflerden birini sunan herhangi biri olabilir. Sonra pencere kapanır ve yönetişim çağrılarında bunlardan hangisinin mantıklı olduğunu tartışırız. İnsanlar argümanlarını sunar, tartışırlar ve yaklaşan o çatallanma için hangisini seçmemiz gerektiği konusunda bir mutabakat sağlanır.

Bunun ardından küçük özellikleri seçerler. Yani gerçekten bu büyük çatallanmayı yönlendiren özellikler olması gerekmeyen daha küçük şeyler. Ve tüm bu süre boyunca özelliğe özgü geliştirici ağlarımız (devnet) olur. Bir geliştirici ağı, bir test ağı gibidir — geliştiricilerin bu özellikleri test etmeleri ve Ethereum'da gerçekten çalıştıklarından emin olmaları için özel bir test ağıdır. Ve sonra bir noktada özellik dondurma (feature freeze) olur. Yani ana özellikleri tartıştık, küçük özellikleri tartıştık, genellikle çatallanmanın ana hatları olan bu özelliğe özgü geliştirici ağlarını çalıştırdık. Ve bu, yıldız işaretli bir özellik dondurmadır çünkü o noktada bu çatallanmaya daha fazla özellik eklemeyeceğimize karar vermişizdir. Tüm özellikleri birlikte çalıştıracağız, her şeyin iyi olduğundan emin olacağız, hiçbir şeyin bozulmayacağından emin olacağız. Ancak bir şeyler işleri yavaşlatmaya başlarsa, çatallanma gecikirse, çok karmaşıksa, o noktada bazı şeyler hâlâ çıkarılabilir.

Yani bir dizi geliştirici ağından sonra — iki olabilir, 10 olabilir — istemcilerin hepsi bir noktada bunun kararlı olduğuna karar verir. Şu anda olup bitenlere güveniyoruz. İyi bir yerdeyiz. Bunu Ethereum ana ağına çıkarmayı düşünmeye başlayalım. İstemci sürümlerini yayınlarlar ve ardından EF güvenlik ekibinin bir hata ödül programı başlattığı 30 günlük bir süre vardır. Güvenlik denetimleri için sözleşme yaparlar. Ve sonra o 30 günlük sürenin sonunda çatallanmayı test ağlarında başlatırız. Bunlar duymuş olabileceğiniz test ağlarıdır — Holesky gibi. Bunlar, uygulama geliştiricilerinin çatallanma yayına girmeden önce kendi işlerini test edebilecekleri yerlerdir. Ve her şeyin yolunda olduğundan emin olmak için bunlar genellikle her biri için en az 14 gündür. Herhangi bir büyük sorun beklemiyoruz çünkü daha önce özelliğe özgü geliştirici ağlarından ve genelleştirilmiş geliştirici ağlarından geçti, ancak tarihsel olarak bu test ağlarından bazılarını bozduğu oldu. Ve bu yüzden bu, tüm bu hataları bulup çözmek için bir nevi son çağrıdır.

Ve sonra izinsiz test ağı kararlı hale geldiğinde, ana ağ tarihi seçilir. Bunun ardından 30 günlük bir tampon süre vardır. Bu 30 günlük tampon süre, Katman 2'lerin (L2) ve protokollerin çatallanmaya hazırlanmak için bunu talep etmesi nedeniyle mevcuttur. Yani bu en az 30 gündür ve ardından çatallanma gerçekleşir.

Çağrı yapısı ve koordinasyon (15:01)

Tüm bu süre boyunca gerçekleşen bazı ana çağrı serileri vardır. Bunların hepsi YouTube'da canlı yayınlanan halka açık çağrılardır. Başlıcaları ACDE ve ACDC'dir. E, yürütme katmanı (execution layer) içindir — bu, işlemler, akıllı sözleşme dağıtımları, bellek havuzu yönetimi gibi şeylerdir. ACDC, mutabakat katmanıdır (consensus layer) — yani bu, doğrulayıcı yönetimi, kesinti (slashing) gibi doğrulayıcı şeyleridir. Ve bunlar perşembe günleri dönüşümlü olarak yapılır. Yani her perşembe bir ACD vardır ve bunlardan biri ACDE'dir ve sonraki ACDC'dir, bu şekilde devam eder.

ACDE ve ACDC çağrıları, şu anda yapmakta olduğumuz çatallanmaya ve gelecek için kapsamını belirlediğimiz çatallanmalara odaklanır. ACDT çağrıları ise daha çok işin ince ayrıntılarıyla ilgilidir. Bunlar, istemcilerin aşamadıkları hatalar veya şu anda üzerinde çalıştıkları çatallanma hakkında çözülmesi gereken uygulama ayrıntıları hakkında konuşmalarıdır. Yani şu anda gerçekleşecek bir sonraki çatallanma Glamsterdam'dır. Bu yüzden bu ACDT çağrılarına, Glamsterdam'a girecek olan ePBS ve blok düzeyinde erişim listeleri hakkındaki konuşmalar hakimdir. Ve bunlar son derece teknik çağrılardır.

Ve bir de ara çağrılar (breakout calls) vardır. Ara çağrılar, topluluk üyelerinin, araştırmacıların, geliştiricilerin "Hey, bundan iki çatallanma sonra Ethereum'a girmesini istediğim bir özelliğim var." demesidir. Ve böylece, uygulama ayrıntılarını tartıştıkları, spesifikasyon üzerinde değişiklik yapıp yineledikleri ve genel olarak insanların sahip olduğu tüm soruları, bilinen tüm bilinmeyenleri ele aldıkları haftalık, aylık veya iki ayda bir yapılan bu çağrılara ev sahipliği yaparlar; böylece bundan iki çatallanma sonraki çatallanmaya dahil edilmek için mümkün olan en iyi yerde olduğundan emin olurlar. Ve bunlar kolaylaştırıcı ne zaman karar verirse o zaman planlanabilir.

Gelişen bir süreç (15:29)

Yani herkese vurgulamak istediğim bir şey, bu sürecin statik olmaktan çok uzak olduğudur. Size az önce anlattığım bu süreç bir yıldan daha kısa bir süredir yayında. Ethereum 10 yıldır yayında. Ancak sürekli değişiyor ve sürekli değişmesinin nedeni kimsenin sorumlu olmamasıdır. Ve bu süreç, çalışmanın en verimli yolunu bulmak için bir nevi evrimleşiyor. Ve verimli diyorum ama Ethereum yönetişiminin sahip olduğu itibar gerçekten durgun, bir şeyleri kabul ettirmenin zor olduğu, kafa karıştırıcı bir süreç olduğudur — ve bunun nedeni, karar veren 100 ila 500 kişi olduğunda, bunun hiç çalışabilmesine dürüst olmak gerekirse hayran kalıyorum.

Bu yüzden Tim, Nisan 2025'te "Tüm Çekirdek Geliştiricileri Yeniden Yapılandırmak" (Reconfiguring All Core Devs) adlı bir gönderi paylaştı ve bu, işlerin şu anda nasıl yürüdüğüne dair bir teklif haline geldi. Ve bunun nedeni, bundan önce Ethereum'da neye odaklanmamız gerektiğine dair uyumlu bir anlatıya sahip olmamızdı. Büyük bir girişim olan Birleşme vardı. Herkes çok heyecanlıydı. Çoğu insan çok heyecanlıydı. Madenciler değildi. Ve sonra Birleşme'nin ardından para çekme işlemleri geldi. Yani, insanların ETH'lerinin bir sözleşmeye kilitlenmesini ve bu FUD'un (korku, belirsizlik ve şüphe) ETH'yi buradan asla çıkaramayacaklarmış gibi olmasını istemedik. Bu yüzden bunu olabildiğince hızlı bir şekilde göndermeliydik. Ve sonra Proto-Danksharding vardı ve ardından Pectra geldi ve Pectra, birbiriyle ilgisiz farklı EIP'lerin bir karışımı gibiydi ve gerçekten uyumlu bir anlatısı yoktu. Ve o kadar büyüdü ki, insanlar uyum eksikliği nedeniyle bir şeyleri içeri tıkıştırdıkları için iki farklı çatallanmaya bölünmek zorunda kaldı çünkü test ekipleri "Kapsam çok büyük. Tüm bunları test edemeyiz." diyordu.

Ve böylece Tim'in bunu yapma itici gücü şuydu: Tamam, bu çatallanmaları olabildiğince odaklanmış ve uyumlu tutmanın bir yolunu düşünmeliyiz. Ve ana teklif (headliner) buna bir nevi cevaptı. Bunun amacı, herkesin çatallanmanın ne hakkında olduğunu bildiğini hissettirmeye öncelik verecek şekilde göndermekti, böylece 25 farklı EIP'yi içeri tıkıştırmak zorunda kalmayacaklardı.

Yani üstteki diğer ekran görüntüsü, Tim'in bu EIP'ler için dahil edilme aşamalarının tanımlarını önermesidir. Ve bununla belirtmek istediğim nokta, bazen insanların bu sürecin çok bürokratik olduğunu söylediğini duyarsınız. Ancak gerçekte olan şey, insanların bu yönetişim sürecine gelip "Bir EIP'yi nasıl dahil edebilirim?" demesi ve 10 yıldır orada olan insanların "Bir şekilde yapıyorsun işte." demesidir. Ve insanlar "Bu korkunç." diyor. Ve böylece bu şeylerin yaptığı şey, dışarıdan gelenlerin bu sürece katılmasını kolaylaştırmak için neler olduğunu açıklamaktır, çünkü buraya yeni geliyorsanız ve "Bir EIP'm var, Ethereum yönetişimini umursamıyorum, sadece bu EIP'nin girmesini istiyorum" diyorsanız — bir yönerge istersiniz, bir kontrol listesi istersiniz, bu EIP'yi nasıl dahil edeceğinize dair çok net bir adım adım kılavuz istersiniz. Yani, bu şeylerin çoğu, EIP'lerin dahil edilmesini zorlaştırmak için insanların uyması gereken bürokratik kurallar oluşturmaktan ziyade sürecin nasıl işlediğini açıklamakla ilgilidir.

Üçüncü şey, Forkcast'teki zaman içindeki işlemelerdir (commits). Forkcast, ekibim tarafından, ekibimin şu anki haliyle kurulduğu geçen yılın ortalarında bunu yaratan ekibimdeki bir adam olan Wolfram Mark tarafından oluşturulan bir üründür. Ve insanların bir çatallanma ile etkileşime girmek, bir çatallanmaya neyin girdiğini ve onları nasıl etkilediğini görmek için kullanabilecekleri çok temel bir kaynak haline geldi. Tüm bu şeyler iki yıldan daha yenidir. Yani sadece belirtmek istediğim nokta, bu sürecin çok değiştiğidir. Hiç de statik değil. Kapıdan içeri adım atmanın zor olduğu donmuş bir bürokrasi değil.

Karşılaştırılabilir yönetişim sistemleri (20:21)

Bu yüzden kısaca Ethereum yönetişimine görebildiğim en benzer merkeziyetsiz yönetişim sistemlerine değinmek istedim. Ve burada anlatmaya çalıştığım nokta, bunun sürdürülebilir olduğudur — 100 ila 500 kişinin karar verebilmesi şaşırtıcı olsa da, gerçek dünyada sürdürülebilirdir. Bunun işe yaradığına dair örnekler görüyoruz.

IETF, İnternet Mühendisliği Görev Gücü'dür (Internet Engineering Task Force). TCP/IP, HTTP'yi yaratan gönüllüler tarafından yürütülen standartlar organıdır. Bugün özgür internete sahip olmamızdan en çok sorumlu olan kuruluştur. Linux çekirdeği — Linux işletim sisteminin çekirdeğidir. Yani internet sunucularına, Android telefonlara, süper bilgisayarlara güç veren açık kaynaklı yazılımdır. Oradaki fark, Linus Torvalds ile bir nevi yardımsever diktatör modeline sahip olmalarıdır. Ancak o zaman bile 17.000'den fazla katkıda bulunanları var ki bu akıllara durgunluk verici.

Bunun benzemediği şeyler: zincir içi token oylamasına sahip diğer blokzincirler. Ethereum özellikle her türlü oylama mekanizmasından kaçınır çünkü bence bu, ele geçirme yollarına yol açar ve insanların sadece en iyi kodu yazan kişilere güvendiği bir meritokrasi yapma teşvikini bir nevi ortadan kaldırır. Ve bir de Katman 2'ler (L2) var. Çoklu imzaları (multi-sig) var. Güvenlik konseyleri var. Bunlar daha çok bu kararları veren atanmış pozisyonlar gibidir. Ve bunun kendi ödünleşimleri (trade-offs) vardır. Daha merkezidir. Ancak daha hızlı hareket eder.

Geliştiriciler neden umursar (22:38)

Peki geliştiriciler yönetişimi neden umursar? Çünkü geliştiriciler kelimenin tam anlamıyla Ethereum'un yaratıldığı kişilerdir. Ethereum çekirdek geliştiriciler için yaratılmamıştır. Doğrulayıcılar için yaratılmamıştır. Bazen bu insanlar bu konuda kafaları karışır. Ethereum çekirdek geliştiricileri ve doğrulayıcıları, geliştiricilere ve kullanıcılara hizmet eden Ethereum'a hizmet eder.

Ve herkes bir yapay zeka ile o anı yaşamıştır; çok fazla ayrıntıya girersiniz ve o bu küçük şeyi düzeltmeye çalışır ve uzaklaşıp projenin tüm amacına bakmayı başaramaz. Ve çekirdek geliştiriciler de çekirdek geliştirme sürecini mükemmelleştirmeye çalışırken böyle olabilirler. Ve bu durumda geliştiricilerin devreye girmesi çok önemlidir çünkü çekirdek geliştirme o kadar her şeyi tüketen bir süreçtir ki çoğu zaman Ethereum'un üzerine de bir şeyler inşa etmezler. Çekirdek geliştirmeye çok dahil olurlar. Tüm zamanlarını alır. Ve bu yüzden uygulama geliştiricilerinin gerçekten gelip "Hey, buna ihtiyacımız var. Bu Ethereum için çok önemli." demek için çaba göstermeleri gerekir. Sadece perspektifin orada olduğundan ve sadece çekirdek geliştiriciler için çalışmaya hapsolmadıklarından emin olmak için.

Nasıl katılınır (24:40)

Peki nasıl katılırsınız veya özelliğinizi nasıl dahil edersiniz? Bu biraz genel bir tavsiye ama bence en iyisi. Sıkıntı yaşadığınız noktalar hakkında sesinizi duyurun. Twitter'a girin, blog yazıları yazın, sıkıntı yaşadığınız noktalar için çözümler belirleyin. Size yardımcı olabilecek şeyler hakkında fikir yürütün. Aynı sıkıntıları yaşayan başka insanlar bulursanız, genellikle o sıkıntıyı gidermek için var olan bir EIP bulabilir veya bunu yapan bir EIP yazmanıza yardımcı olacak birini bulabilirsiniz.

Açık kaynaklı yazılımlar hakkında sevdiğim bir şey, genellikle iyi sermayelendirilmiş şirketlerin geliştirici zamanlarını ve kaynaklarını kullandıkları açık kaynaklı araçları sürdürmeye ayırmalarıdır. Ve sonuçta bu şeyi sürdürmek için işbirliği yapan bir grup farklı şirket ortaya çıkar ve bu Ethereum'da da böyle işleyebilir. Yani belirlediğiniz bir sıkıntı noktanız varsa, benzer bir sıkıntı noktasına sahip bir Base geliştiricisi bulabilirsiniz ve Base iyi sermayelendirilmiş bir kuruluştur ve bu nedenle muhtemelen bir özelliği göndermek veya bir özelliği bir Ethereum sert çatallanması yoluyla yönlendirmek için bazı kaynaklar ayırmaya istekli olacaklardır.

Size sadece bazı kaynaklar bırakacağım. Forkcast.org — burası gidip bir çatallanmaya nelerin girdiğine, belirli paydaşları nasıl etkilediğine bakabileceğiniz yerdir. Yani, bir uygulama geliştiricisiyseniz, uygulama geliştiricileri için bir bölüm var. Bir Cüzdan geliştiricisi, bir mutabakat katmanı istemci geliştiricisiyseniz, tüm bunların sizi nasıl etkilediğine dair bölümler var. YouTube, tüm bu çağrı videolarının yüklendiği yerdir. Ayrıca özetlerin, konuşmacı atıflarının bulunduğu forkcast.org/calls sayfasına da gömülüdürler, böylece bu çağrılarda gezinmek daha kolaydır. EIP'ler dizini, potansiyel çözümler veya yazmak istediğiniz EIP'ler hakkında diğer insanlarla konuşabileceğiniz Ethereum Magicians forumu. Ve çok yakında ekibimin bir protokol destek sitesi olacak. Harika görünüyor. Paylaşmaya hazır değil. E-postam da orada — nixo@ethereum.org (opens email client). Bu kadar.