Ethereum'un kurucusu V God, bazı geliştiricilerin şüphelenmesine neden olan geçmiş EVM'yi değiştirmek için yürütme katmanında "RISC-V"yi Ethereum ile değiştirmeyi önerdi ve 2016'da Ethereum geliştiricisi OG, bunun Ethereum ekosistemini yeniden dağıtımla karşı karşıya bırakacağına ve küçük sermaye projelerine karşı çok düşmanca olacağına inanıyordu. (Özet: Ethereum'un işlem ücretleri beş yılın en düşük seviyesine ulaştı ve topluluk "L2 zehir teorisini" başlattı: yolda araba yok ve V God hala gülüyor ve otoyollar inşa ediyor) (Arka plan eki: Vitalik'in Ethereum'un yönetici katmanını "EVM yerine RISC-V" ile yeniden inşa etme stratejik hırsını ortadan kaldırmak) Ethereum kurucusu V God'ın son "RISC-V" önerisi, kripto topluluğunun dikkatini çekti ve çekirdek ekosistem geliştiricileri arasında tartışmalara neden oldu ve çoğu kullanıcı için çoğu RISC-V'yi anlayamıyor Ethereum'da nasıl reform yapılır ve V-God'ın önerisi Ethereum'a ne tür bir ilerleme sağlayabilir? Bu soruyu cevaplamak için, 2016'dan beri Ethereum'un çekirdek ekolojisini geliştiren eski bir OG "anti-scale dragon" ile röportaj yaptık ve ayrıntılı "RISC-V" revizyon sürecini ve gelecekte oluşabilecek kısa vadeli olumsuz etkileri yanıtlayacak ve tüm Ethereum yatırımcılarına bu teklifin takibine çok dikkat etmelerini hatırlatacak. RISC-V durumu nasıl yenilenir Ethereum, Ethereum istemcisinin "konsensüs katmanı" ve "yürütme katmanı" olmak üzere iki bölümden oluşması ve konsensüs katmanının stake oylamasının paketlenmesinden sorumlu olması ve yürütme katmanının işlemlerin işlenmesinden sorumlu olması bakımından diğer PoS zincirlerinden farklıdır, bu nedenle akıllı sözleşmeyi yürüten kod aslında düğüm bilgisayarı tarafından çalıştırılan, işlem yayınını alarak kodu çalıştıran ve oylama sonuçlarını halka açık defterdeki "konsensüs katmanı" aracılığıyla yazan bir yürütme katmanı istemcisidir. Mevcut EVM ortamını RISC-V'ye yükseltmenin tek yolu, Ethereum bloğunu ve ilgili düğüm revizyonunu değiştirmek için geçmişteki olağan hard fork'un aksine, yalnızca yazılım düzeyinde bir çatal olan düğüm istemcisinin "yürütme katmanı istemcisini" güncellemektir. V God'ın makalesinin içerik açıklamasına göre, ideal olarak, tüm düğüm istemcilerinin RISC-V yürütücüleri varsa, yeni sürüm için protokolün çalışması ve zk kanıtının çalışması teorik verimliliğin yaklaşık 100 katına ulaşabilir, ancak bunun, EVM istemcisinde yürütülen EVM akıllı sözleşme formatına göre RISC-V sürümü ve RISC-V istemcisi için akıllı sözleşmede hesaplandığı bilinmelidir. RISC-V'nin bu seferki önerisiyle ilgili özel olan şey, doğrudan yönetici katmanı istemcisinde yenilenmesi ve pek sevmediğim hard fork kısmını kullanmayacak olması, ancak Ethereum'un yeni bir yönde ilerlediği görülebilir, bu iki ucu keskin bir kenar olabilir ve geçmişteki bu değişiklik seviyesi Ethereum, daha güvenli bir yaklaşım olabileceğinden bir hard fork ile uygulanmayı seçebilir. Mevcut durum ile eski sözleşme arasındaki yazışmalar Teorinin performansını anladıktan sonra, mevcut durumun ne olduğuna bakalım, mevcut durum, Ethereum'un tüm ekolojisinin ve tüm EIP uygulamalarının EVM akıllı sözleşmeleri ve EVM istemcileri aracılığıyla başarıyla yürütülmesidir, eğer V God'ın dediği gibi RISC-V'nin bir EVM aktarıcısı olacaksa, o zaman gerçek gelecekteki durum aşağıdaki durumlara ayrılabilir EVM akıllı sözleşmeleri EVM istemcisinde çalışır (eski EIP tamamen uyumludur, ancak yeni EIP'nin iki sürüme karşılık gelmesi gerekir) EVM akıllı sözleşmesi, RISC-V'nin EVM aktarıcısı aracılığıyla RISC-V istemcisinde çalışır (eski ve yeni EIP'lerin çözmek için çok sayıda test ve hata ayıklamadan geçmesi gerekir) RISC-V akıllı sözleşmesi, RISC-V istemcisinde çalışır (eski EIP'nin tümü yeniden test edilecektir, ancak yeni EIP mükemmel bir şekilde uyumlu olmalıdır) Özetle, gelecekteki akıllı sözleşme operasyon verimliliğinin 100 kat teorik performansı göz önüne alındığında, yalnızca üçüncü durum uygulanabilir ve ikinci durum için, Özellikle, Ethereum çekirdek ekibinin aktarıcı optimizasyonunun yanı sıra geçmişteki tüm EIP yükseltmelerine ve akıllı sözleşmelere dayanır, bu da Ethereum'un teorik performans iyileştirmesi elde etmek için çok büyük bir optimizasyon fiyatı ödemesi gerektiği anlamına gelir ve RISC-V'de çeviri yoluyla eski EVM kodunun verimlilik optimizasyonunun kesinlikle yerel EVM ortamınınkinden daha büyük olup olmadığı belirsizdir. Aslında, V God bunu söyledi, sanırım geçmişte EVM geliştirmede her bir EIP uygulamasını ve testini çözmek için çok çaresiz hisseden birçok çekirdek geliştirici olmalı, iş yükü zaten çok büyük, çünkü Ethereum çok açık bir ortamda açık cevapları test etmeyi seven bir topluluk. Ama şimdi bir RISC-V ortamı haline geldiğinde, sadece dönüşümün test dönemini düşünüyorum, ki bu çok baş ağrısı, temel sorun şu ki, test süresi boyunca orijinal ortamdan 1~5 kat daha verimli çalışamayabilirsiniz, bu yüzden sanırım bu test süresi, tıpkı geçmişte Ethereum Merge gibi birçok kez uzatılmaya devam edecek, bu nedenle erken aşamada somut sonuçların eksikliği var ve test ağında konuşlandırılmak ve geri bildirim göndermek için dış ekosistemleri çekmek zor. Sadece V God'ın büyük hırsları olduğunu söyleyebilirim, ancak uygulamanın çok iyimser olduğunu düşünmüyorum, en azından çekirdek geliştiricilerin yarısından fazlasının çok mutlu olmayabileceğini düşünüyorum, eğer RISC-V'ye geçmeye kararlılarsa, V God ve Ethereum Vakfı'nın çekirdek geliştirici ekibini ve ekolojiyi teşvik etmek için çok çaba harcaması gerekiyor. RISC-V ile ekolojik yazışma sorunu Ejderha, RISC-V önerisinin en büyük sorununun özel proje ekolojisinin desteğinden ve yazışmalarından gelebileceğini, mevcut açık kaynak ekosisteminde kullanılabilecek bileşenlerin çok sınırlı olduğunu, bu nedenle V God tarafından önerilen EVM'den RISC-V'ye çeviri sloganının kısa vadede birçok şüphe ve sorunu olabileceğini belirtti. Örneğin, EVM'den RISC-V'ye çeviri öncülüğünde EVM projeleri ve sorunsuz sözleşmeler gibi Ethereum'un mevcut ekosistemi, sözleşmenin yürütme katmanında yürütülmesi sürecinde durum eksikliği veya operasyonların sona ermesi olabilir, bu da geçmişte herhangi bir sorun yaşamamış eski EVM projelerinin bile, EVM'den RISC-V'ye çeviri kullanılması durumunda, önerilemeyen veya yanlışlıkla yakılan veya kilitlenen belirteçler olabileceği anlamına gelir. Böyle bir örnek, ekolojik proje ekibinin, bazı durumlarda, kullanıcıları eski EVM akıllı sözleşmelerini çalıştırmak için EVM'den RISC-V'ye aktarıcıyı kullanmaya açma konusunda isteksiz hale getirmesi çok muhtemeldir; Buna ek olarak, ilgili risklerden kaçınmak ve Ethereum'un yeni teknolojisini takip etmek için proje ekosistemi için en iyi yol, tüm akıllı sözleşmeler için sözleşmenin yeni bir RISC-V versiyonunun yazılmasıdır ve eski sözleşme ile yeni sözleşme arasındaki bağlantı varlık köprüleme yoluyla çözülür. Aslında, uyumluluğa girmenin yolunun paketlenmesi çok kolaydır, ancak vakıf genel çözümü elde etmek için para dağıtmaya istekliyse, uyumluluk sorunlarının% 99'unu çözebilir, ancak sorun kalan% 1'de ve ekolojik geliştiricilerin güvenlik güveninde yatmaktadır. Şimdi Ethereum'un proje geliştiricilerine soruyorsunuz, sanırım EVM çevirisi RISC-V kısmına o kadar güvenmeyeceğim, büyük sermayeli teknoloji şirketleri baştan sona kendi özel sistemlerine veya çiplerine ait olmak istiyorlar, mutlaka RISC-V'yi seçmeyecekler, çünkü bu mimari açık kaynak olmasına rağmen, ARM ve X86 gibi ana akım mimarilere kıyasla, RISC-V ekolojik desteği çok sınırlıdır ve blok zincirinin ilgili bir gelişimi yoktur, bu da Ethereum'un çıplak elle bir dünya açması gerektiği anlamına gelir. Sınavda ise...
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Ethereum "RISC-V'ye geçiyor" geliştiricileri korkutuyor mu? OG uyarıyor: ETH ekosistemi yeniden dağıtılacak, küçük projeler Solana'ya gidecek.
Ethereum'un kurucusu V God, bazı geliştiricilerin şüphelenmesine neden olan geçmiş EVM'yi değiştirmek için yürütme katmanında "RISC-V"yi Ethereum ile değiştirmeyi önerdi ve 2016'da Ethereum geliştiricisi OG, bunun Ethereum ekosistemini yeniden dağıtımla karşı karşıya bırakacağına ve küçük sermaye projelerine karşı çok düşmanca olacağına inanıyordu. (Özet: Ethereum'un işlem ücretleri beş yılın en düşük seviyesine ulaştı ve topluluk "L2 zehir teorisini" başlattı: yolda araba yok ve V God hala gülüyor ve otoyollar inşa ediyor) (Arka plan eki: Vitalik'in Ethereum'un yönetici katmanını "EVM yerine RISC-V" ile yeniden inşa etme stratejik hırsını ortadan kaldırmak) Ethereum kurucusu V God'ın son "RISC-V" önerisi, kripto topluluğunun dikkatini çekti ve çekirdek ekosistem geliştiricileri arasında tartışmalara neden oldu ve çoğu kullanıcı için çoğu RISC-V'yi anlayamıyor Ethereum'da nasıl reform yapılır ve V-God'ın önerisi Ethereum'a ne tür bir ilerleme sağlayabilir? Bu soruyu cevaplamak için, 2016'dan beri Ethereum'un çekirdek ekolojisini geliştiren eski bir OG "anti-scale dragon" ile röportaj yaptık ve ayrıntılı "RISC-V" revizyon sürecini ve gelecekte oluşabilecek kısa vadeli olumsuz etkileri yanıtlayacak ve tüm Ethereum yatırımcılarına bu teklifin takibine çok dikkat etmelerini hatırlatacak. RISC-V durumu nasıl yenilenir Ethereum, Ethereum istemcisinin "konsensüs katmanı" ve "yürütme katmanı" olmak üzere iki bölümden oluşması ve konsensüs katmanının stake oylamasının paketlenmesinden sorumlu olması ve yürütme katmanının işlemlerin işlenmesinden sorumlu olması bakımından diğer PoS zincirlerinden farklıdır, bu nedenle akıllı sözleşmeyi yürüten kod aslında düğüm bilgisayarı tarafından çalıştırılan, işlem yayınını alarak kodu çalıştıran ve oylama sonuçlarını halka açık defterdeki "konsensüs katmanı" aracılığıyla yazan bir yürütme katmanı istemcisidir. Mevcut EVM ortamını RISC-V'ye yükseltmenin tek yolu, Ethereum bloğunu ve ilgili düğüm revizyonunu değiştirmek için geçmişteki olağan hard fork'un aksine, yalnızca yazılım düzeyinde bir çatal olan düğüm istemcisinin "yürütme katmanı istemcisini" güncellemektir. V God'ın makalesinin içerik açıklamasına göre, ideal olarak, tüm düğüm istemcilerinin RISC-V yürütücüleri varsa, yeni sürüm için protokolün çalışması ve zk kanıtının çalışması teorik verimliliğin yaklaşık 100 katına ulaşabilir, ancak bunun, EVM istemcisinde yürütülen EVM akıllı sözleşme formatına göre RISC-V sürümü ve RISC-V istemcisi için akıllı sözleşmede hesaplandığı bilinmelidir. RISC-V'nin bu seferki önerisiyle ilgili özel olan şey, doğrudan yönetici katmanı istemcisinde yenilenmesi ve pek sevmediğim hard fork kısmını kullanmayacak olması, ancak Ethereum'un yeni bir yönde ilerlediği görülebilir, bu iki ucu keskin bir kenar olabilir ve geçmişteki bu değişiklik seviyesi Ethereum, daha güvenli bir yaklaşım olabileceğinden bir hard fork ile uygulanmayı seçebilir. Mevcut durum ile eski sözleşme arasındaki yazışmalar Teorinin performansını anladıktan sonra, mevcut durumun ne olduğuna bakalım, mevcut durum, Ethereum'un tüm ekolojisinin ve tüm EIP uygulamalarının EVM akıllı sözleşmeleri ve EVM istemcileri aracılığıyla başarıyla yürütülmesidir, eğer V God'ın dediği gibi RISC-V'nin bir EVM aktarıcısı olacaksa, o zaman gerçek gelecekteki durum aşağıdaki durumlara ayrılabilir EVM akıllı sözleşmeleri EVM istemcisinde çalışır (eski EIP tamamen uyumludur, ancak yeni EIP'nin iki sürüme karşılık gelmesi gerekir) EVM akıllı sözleşmesi, RISC-V'nin EVM aktarıcısı aracılığıyla RISC-V istemcisinde çalışır (eski ve yeni EIP'lerin çözmek için çok sayıda test ve hata ayıklamadan geçmesi gerekir) RISC-V akıllı sözleşmesi, RISC-V istemcisinde çalışır (eski EIP'nin tümü yeniden test edilecektir, ancak yeni EIP mükemmel bir şekilde uyumlu olmalıdır) Özetle, gelecekteki akıllı sözleşme operasyon verimliliğinin 100 kat teorik performansı göz önüne alındığında, yalnızca üçüncü durum uygulanabilir ve ikinci durum için, Özellikle, Ethereum çekirdek ekibinin aktarıcı optimizasyonunun yanı sıra geçmişteki tüm EIP yükseltmelerine ve akıllı sözleşmelere dayanır, bu da Ethereum'un teorik performans iyileştirmesi elde etmek için çok büyük bir optimizasyon fiyatı ödemesi gerektiği anlamına gelir ve RISC-V'de çeviri yoluyla eski EVM kodunun verimlilik optimizasyonunun kesinlikle yerel EVM ortamınınkinden daha büyük olup olmadığı belirsizdir. Aslında, V God bunu söyledi, sanırım geçmişte EVM geliştirmede her bir EIP uygulamasını ve testini çözmek için çok çaresiz hisseden birçok çekirdek geliştirici olmalı, iş yükü zaten çok büyük, çünkü Ethereum çok açık bir ortamda açık cevapları test etmeyi seven bir topluluk. Ama şimdi bir RISC-V ortamı haline geldiğinde, sadece dönüşümün test dönemini düşünüyorum, ki bu çok baş ağrısı, temel sorun şu ki, test süresi boyunca orijinal ortamdan 1~5 kat daha verimli çalışamayabilirsiniz, bu yüzden sanırım bu test süresi, tıpkı geçmişte Ethereum Merge gibi birçok kez uzatılmaya devam edecek, bu nedenle erken aşamada somut sonuçların eksikliği var ve test ağında konuşlandırılmak ve geri bildirim göndermek için dış ekosistemleri çekmek zor. Sadece V God'ın büyük hırsları olduğunu söyleyebilirim, ancak uygulamanın çok iyimser olduğunu düşünmüyorum, en azından çekirdek geliştiricilerin yarısından fazlasının çok mutlu olmayabileceğini düşünüyorum, eğer RISC-V'ye geçmeye kararlılarsa, V God ve Ethereum Vakfı'nın çekirdek geliştirici ekibini ve ekolojiyi teşvik etmek için çok çaba harcaması gerekiyor. RISC-V ile ekolojik yazışma sorunu Ejderha, RISC-V önerisinin en büyük sorununun özel proje ekolojisinin desteğinden ve yazışmalarından gelebileceğini, mevcut açık kaynak ekosisteminde kullanılabilecek bileşenlerin çok sınırlı olduğunu, bu nedenle V God tarafından önerilen EVM'den RISC-V'ye çeviri sloganının kısa vadede birçok şüphe ve sorunu olabileceğini belirtti. Örneğin, EVM'den RISC-V'ye çeviri öncülüğünde EVM projeleri ve sorunsuz sözleşmeler gibi Ethereum'un mevcut ekosistemi, sözleşmenin yürütme katmanında yürütülmesi sürecinde durum eksikliği veya operasyonların sona ermesi olabilir, bu da geçmişte herhangi bir sorun yaşamamış eski EVM projelerinin bile, EVM'den RISC-V'ye çeviri kullanılması durumunda, önerilemeyen veya yanlışlıkla yakılan veya kilitlenen belirteçler olabileceği anlamına gelir. Böyle bir örnek, ekolojik proje ekibinin, bazı durumlarda, kullanıcıları eski EVM akıllı sözleşmelerini çalıştırmak için EVM'den RISC-V'ye aktarıcıyı kullanmaya açma konusunda isteksiz hale getirmesi çok muhtemeldir; Buna ek olarak, ilgili risklerden kaçınmak ve Ethereum'un yeni teknolojisini takip etmek için proje ekosistemi için en iyi yol, tüm akıllı sözleşmeler için sözleşmenin yeni bir RISC-V versiyonunun yazılmasıdır ve eski sözleşme ile yeni sözleşme arasındaki bağlantı varlık köprüleme yoluyla çözülür. Aslında, uyumluluğa girmenin yolunun paketlenmesi çok kolaydır, ancak vakıf genel çözümü elde etmek için para dağıtmaya istekliyse, uyumluluk sorunlarının% 99'unu çözebilir, ancak sorun kalan% 1'de ve ekolojik geliştiricilerin güvenlik güveninde yatmaktadır. Şimdi Ethereum'un proje geliştiricilerine soruyorsunuz, sanırım EVM çevirisi RISC-V kısmına o kadar güvenmeyeceğim, büyük sermayeli teknoloji şirketleri baştan sona kendi özel sistemlerine veya çiplerine ait olmak istiyorlar, mutlaka RISC-V'yi seçmeyecekler, çünkü bu mimari açık kaynak olmasına rağmen, ARM ve X86 gibi ana akım mimarilere kıyasla, RISC-V ekolojik desteği çok sınırlıdır ve blok zincirinin ilgili bir gelişimi yoktur, bu da Ethereum'un çıplak elle bir dünya açması gerektiği anlamına gelir. Sınavda ise...