"Bu özel Devs on Devs bölümünde, Plasma Mode'un ana protokol geliştiricisi tdot('ı ve aynı zamanda Redstone'un geliştiricisi )'i, ayrıca Optimism'ın kurucu ortağı Ben Jones'u davet ettik. Optimism, OP Stack'in temel itici gücüdür. Plasma Mode, geliştiricilerin OP Stack üzerinde inşa etmelerine olanak tanırken, verileri L1'e yayınlamaları gerekmemektedir; bunun yerine, maliyetleri azaltmak ve ölçeklenebilirliği artırmak için esnek bir şekilde zincir dışı veri sağlayıcılara geçiş yapabilirler. Sohbetlerinde, Redstone ve Optimism iş birliğinin kökenlerini, Plasma'nın yeniden canlandırılmasının önemini, deneysel protokollerin üretim ortamına getirilmesinin gerekliliğini, Plasma Mode ve OP Stack'in gelecekteki yol haritasını ve tüm zincir oyun alanının gelişimine duydukları heyecanı tartıştılar."
Plasma Modunu OP Stack'i Geliştirmek İçin Nasıl Kullanılır
Ben: OP Stack'ı geliştirme süreci nasıl başlıyor?
tdot: Yaklaşık bir yıl önce Lattice'e katıldım ve Plasma Mode'dan sorumluyum. Hedef oldukça net: Birçok MUD uygulamamız var, bunlar büyük miktarda gaz tüketiyor ve aynı zamanda büyük verileri zincire koymaya çalışıyoruz, bu nedenle hem bu ihtiyaçları karşılayabilecek hem de uygun fiyatlı bir çözüme ihtiyacımız var. Lattice ekibi OP Stack üzerinde bazı denemeler yaptı, örneğin bazı zincir üstü dünyaları prototipini oluşturup OP Stack'e dağıttık. OP Stack'in oldukça iyi çalıştığını gördük.
Bu nedenle kendimize sorduk, "Bunu daha ucuz hale nasıl getirebiliriz?" Temel varsayım, "OP Stack'in Ethereum'un felsefesine en uygun ve tamamen EVM ile uyumlu çerçeve olduğunu düşünüyoruz." Ana ağda çalışan şeyler OP Stack'te de çalışabilir, bu ideal bir çözümdür. Ama bunu daha ucuz hale getirmek istiyoruz.
O sırada, calldata hala OP Stack zincirinin veri kullanılabilirliği (DA) kaynağıydı ve bu çok pahalıydı. Bu yüzden, açıkça bir L2 başlatmak için calldata kullanamayız çünkü tam zincir oyunlarımız ve MUD dünyamız daha yüksek bir iş hacmine ihtiyaç duyuyor. Bu nedenle, diğer veri kullanılabilirliği (Alt DA) çözümlerini denemeye karar verdik. Aslında, başlangıçtaki OP Stack belgelerinde Alt DA'yı keşfetmenin önemine zaten değinilmişti.
Bu yüzden kendimize şunu sorduk: "Eğer zincir dışı DA ile başlarsak ne olur?" Tüm güvenlik modelinin ve her şeyin L1 Ethereum'a bağımlı olmasını umuyoruz. Bu nedenle diğer Alt DA çözümlerinden kaçındık ve verileri merkezi DA depolama alanında saklamaya karar verdik, ardından L1 üzerinde etkili bir güvenlik modeli bulmayı hedefledik.
Bu, bazı eski Plasma kavramlarını yeniden kullanmayı ve bunları rollup'un üzerine yerleştirmeyi neden istediğimizdir. Burada bazı farklılıklar var. En büyük soru, mevcut OP Stack üzerinde zincir dışı DA ve zincir içi veri meydan okumasını nasıl gerçekleştireceğimizdir? Amacımız, OP Stack'i mümkün olduğunca az değiştirmek, rollup yolunu etkilememek, çünkü OP Stack'i kullanan diğer rollup zincirlerinin güvenliğini etkilemek istemiyoruz.
Rollup tasarımı yaparken, "Eğer biri veri üretim sürecini değiştirip verileri başka bir yerden saklamak isterse ne olur?" diye düşünmezsiniz. Bu değişiklikler olsa bile, OP Stack hala çok güçlü ve kutudan çıkar çıkmaz harika bir performans sergiliyor. Bu yaptığımız ilk değişiklik.
Sonrasında, bu zorlukları oluşturmak için bir sözleşme yazmamız gerekiyor. Verileri zincire zorla koymak için DA zorlukları var. Bu, sürece sözleşmeyi entegre etmenin ikinci adımıdır. Türetme sürecinde, bütün entegrasyon sistemini inşa etmemiz gerekiyor, böylece bir zincir dışı DA kaynağından ve bir L1 DA zorluk sözleşmesinden veri türetebilirsiniz, böylece veriler zorluk çözüm sürecinde zincire gönderildiğinde.
Bu, meselenin özüdür. Karmaşık çünkü işleri zarif ve sağlam tutmak istiyoruz. Aynı zamanda, bu nispeten basit bir kavram. Her şeyi yeniden icat etmeye veya tüm OP Stack'i değiştirmeye çalışmadık, bunun yerine karmaşık bir ortamda işleri basit tutmaya çalıştık. Yani genel olarak, bu oldukça harika bir mühendislik yolculuğu.
Ben: OP açısından konuşabilirim. Bazı Lattice'in erken çalışmalarından bahsettin. Aynı zamanda, Optimism neredeyse tüm OP Stack'i baştan sona yeniden yazdı, bu sürüme Bedrock adını verdik.
Temelde, rollup'ı inşa ettikten iki yıl sonra, bir adım geri attık ve "Tamam, eğer öğrendiğimiz tüm deneyimleri en üst düzeye çıkarmak istiyorsak, bu nasıl olur?" diye düşündük. Bu, nihayetinde Bedrock olarak adlandırılan kod tabanına dönüştü ve bu, ağımıza yaptığımız en büyük yükseltme.
O zamanlar, sizinle birlikte OPCraft adında bir proje üzerinde çalıştık, bence Biomes onun ruhsal varisidir, bu bizim zincir üzerinde en keyifli oynadığımız zamandı. Aynı zamanda, diğerlerinin de OP Stack kullanarak geliştirme yapabilmesi nedeniyle bir nefes aldık. Son birkaç yıl içinde, ölçeklendirme açısından başka bir önemli dönüm noktasının, birçok kişinin zincir çalıştırabilmesi olduğunu düşünüyorum.
Sadece büyük ve karmaşık kod kütüphaneleri geliştirenlerin bunu yapabileceği anlamına gelmiyor. İşbirliğine başladığımızda, başkalarının bu kod kütüphanesini devralıp harika şeyler yapabildiğini görmek büyük bir onur. Sonra bu durumun gerçek uygulamalarda Plasma'ya genişlediğini görmek gerçekten harika. O tarihle ilgili biraz konuşabilirim.
Optimism, Optimism olmadan önce, aslında Plasma adı verilen bir teknolojiyi araştırıyorduk. O zamanlarda üstlendiğimiz görev, o dönemki ölçeklendirme topluluğunun kapasitesinden çok daha fazlaydı. Erken dönem Plasma tasarımında gördüğünüz tasarım, bugünkü Plasma ile doğrudan bir ilişkiye sahip olmayabilir.
Bugünkü Plasma çok daha basit. Durum doğrulama kanıtlarını ve zorluklarını verinin zorluklarından ayrı olarak ele alıyoruz. Sonuç olarak, birkaç yıl önce Rollup'ların Plasma'dan çok daha basit olduğunu fark ettik. O zaman topluluğun vardığı sonuç "Plasma öldü" idi. Bu, o dönemde Ethereum ölçeklenme tarihinin bir esprisi.
Ama hepimiz "Plasma ölmedi, sadece daha basit bir görevle başlayabiliriz" dedik. Şimdi farklı terimler kullanıyoruz. Örneğin, o zamanlarda ( çıkışları ) gibi kavramlar vardı, şimdi geriye dönüp bakınca "oh, bu bazı ek adımlar içeren bir veri kullanılabilirlik zorluğuydu" diyebilirsiniz. Yani OP Stack'in sadece başkaları tarafından kullanılmadığını, aynı zamanda bizim başlangıçta denediğimiz ama oldukça karmaşık ve olgunlaşmamış bir soyutlama biçimiyle evrildiğini görmek gerçekten harika. Tam bir döngüyü tamamladık, etrafında harika soyutlamalar yaptınız ve bunu mantıklı ve makul bir şekilde çalıştırdınız. Bu gerçekten çok havalı.
En önemli olan, üretim ortamına mümkün olan en kısa sürede geçmektir.
tdot: Plasma modu hala bazı zorluklar ve çözülmemiş sorunlar barındırıyor, bunları çözmek için çalışıyoruz. Anahtar, on yıl süren bir zaman kaybını nasıl önleyeceğimizdir? Ne demek istediğimi anlıyor musun? Sonuç elde edebileceğimiz aşamaya bir an önce ulaşmamız gerekiyor.
Bu bizim düşüncemiz. MUD tabanlı birçok uygulamamız var ve bunları hemen ana ağda başlatmak istiyoruz. Bu oyunlar için mümkün olan en kısa sürede bir ana ağ hazırlamamız gerekiyor. İnsanlar bekliyor ve hazırlar. Tüm bu uygulamaları çalıştırmak için hızlı bir şekilde başlatılabilen ve çalışabilen bir zincire ihtiyacınız var, böylece bu uygulamalar, sorunları çözerken paralel olarak gelişebilir ve daha iyi hale gelebilir. Ar-ge'den üretim istikrarına geçiş uzun zaman alıyor.
Bir şeyi ana ağa çıkarmak, onun izinsiz, sağlam ve güvenli olmasını sağlamak için büyük miktarda zaman harcamak gerekiyor. Bu hedefe ulaşma sürecimizi görmek gerçekten etkileyici. Bu yüzden yüksek düzeyde çevik kalmamız gerekiyor çünkü çok fazla şey var. Tüm ekosistem çok hızlı gelişiyor. Herkesin büyük miktarda yenilik sunduğunu düşünüyorum. Bu yüzden ayak uydurmalısınız, ancak güvenlik ve performansta da taviz verememelisiniz, aksi takdirde sistem çalışamaz.
Ben: Ya da teknik yük demek. Bahsettiğin en az değişiklik ilkesi, Bedrock yeniden yazımımızın temel ilkelerinden biri. Uçtan uca yeniden yazımı konuştum, ama daha da önemlisi, yaklaşık 50,000 satır kodu azalttık, bu başlı başına çok güçlü. Çünkü haklısın, bu işler gerçekten zor.
Her bir kod satırı eklemek, sizi üretim ortamından daha da uzaklaştırır, işlerin gerçek testlerden geçmesini zorlaştırır ve daha fazla hata fırsatı getirir. Bu nedenle, bu süreci ilerletme konusundaki tüm çabalarınız için özellikle OP Stack'in yeni operasyonel modeli için yaptığınız katkılara çok teşekkür ederiz.
tdot: OP Stack gerçekten bu tür şeylerde hızlı ilerlemenizi sağlayan bir yol yarattı. Herkesi koordine etmek çok zor çünkü açıkça iki farklı şirketiz. Lattice'de bir oyun, bir oyun motoru ve bir zincir inşa ediyoruz.
Ve siz yüzlerce, binlerce şey inşa ediyorsunuz ve bu ürünlerin hepsini düzenli olarak teslim ediyorsunuz. Koordinasyon açısından bu gerçekten çok zor.
Ben: Evet, gerçekten daha kat edecek çok yol var. Ama bu, modülerliğin çekici olmasının temel nedenlerinden biri. Benim için, OP Stack açısından bakıldığında, bu en heyecan verici şeylerden biri, Redstone üzerinde inşa edilen o muhteşem oyunlar ve sanal dünyaları bir kenara bırakırsak. Sadece OP Stack açısından bakıldığında, bu çok güçlü bir örnek; birçok harika ana geliştiricinin buraya katıldığını ve bu yığın üzerinde iyileştirmeler yaptığını kanıtlıyor, bu gerçekten harika.
Bu ilk sefer, bir anahtar Boolean değeri ile sistemin özelliklerini önemli ölçüde değiştirebilirsiniz. Bunu tamamen başarmak, belirttiğin gibi, gerçekten uzun bir yol var. Ama bunun neredeyse etkili bir şekilde yapılabilmesi için modüler desteğe ihtiyaç var, değil mi? Bizim için, bunun gibi L2 Geth'i yeniden yazmadan başardığınızı görmek gerçekten rahatlatıcı. Bu benim için modülerliğin işe yaradığını kanıtlıyor.
tdot: Şu anda durum daha iyiye gitti. Bu örneğe bakıldığında, her şeyi bağımsız küçük modüllere dönüştürdünüz, ayarlanabilir ve özellikleri değiştirilebilir. Bu yüzden hangi yeni özelliklerin entegre edileceğini görmek için çok heyecanlıyım. Hatırlıyorum da, endişelendiğimiz şey, OP Stack'teki tüm değişiklikleri içeren bir fork'umuzun olmasıydı ve bunun ana kısma birleştirilmesi gerekiyordu. O zaman "Aman Tanrım, her şeyi gözden geçirmek çılgınca olacak" diye düşündük.
Bunu daha küçük parçalara ayırmak zorunda kaldık, ancak tüm süreç oldukça sorunsuz geçti. Takımla işbirliği ortamımız çok iyiydi, bu yüzden inceleme süreci de oldukça keyifliydi. Bu çok doğal hissettiriyordu. Ayrıca, bazı potansiyel sorunları inceleme ve çözme konusunda bu sürecin oldukça hızlı ilerlediğini düşünüyorum. Her şey beklenmedik şekilde sorunsuz geçti.
Ben: Bu gerçekten harika. Bu yılki önceliklerimizden biri OP Stack için katkı yolları oluşturmak. Bu süreçlere katıldığınız için çok teşekkür ederim. Bu süreçlerin katlanılmaz olmadığını ve bazı sonuçlar elde ettiğimizi duyduğuma sevindim. Bu noktada, senin bakış açına göre, bu çalışmanın nasıl gelişeceğini merak ediyorum? Gelecekte en çok hangi geliştirmeyi bekliyorsun?
tdot: Farklı iş yönleri var. Temelde arıza kanıtlama mekanizmasının entegrasyonu ile ilgilidir. Tüm teknik yığınları merkeziyetsizleştirmek ve izin gerektirmeyen özelliklerini artırmak için kademeli bir yaklaşım benimsiyoruz; nihai hedef, izin gerektirmeyen ve zorunlu çıkış gibi işlevleri gerçekleştirmektir.
Bu nihai amacımız var ve güvenliği sağlarken bunu kademeli olarak gerçekleştirmekteyiz. Bir zorluk, bazen ana ağa geçmemek daha kolaydır çünkü böylece sert çatal yapmaya gerek kalmaz. "Ah, her şey tamamen hazır olana kadar yayınlamayı beklersem, böylece sert çatal yapmam gerekmeyecek ve teknik bir yüküm de olmayacak" diye düşünebilirsiniz. Ancak, ana ağda hızlı bir şekilde çevrimiçi olmak istiyorsanız, bu karmaşık yükseltmeleri ele almalı ve sık sık yayın yapmalısınız. Bunu başarmak ve yüksek kullanılabilirliği korumak her zaman bir zorluktur.
Arıza kanıtı mekanizması ve tüm bu parçalar hazır olduğunda, Plasma modeli açısından birçok yükseltme olacağını düşünüyorum. Toplu taahhütlerin sunulması konusunda hala bazı optimizasyon fırsatları olduğunu düşünüyorum. Şu anda her işlem için bir taahhüt ile basit bir şekilde yapıyoruz. Ve taahhüt, yalnızca zincir dışı depolanan girdi verilerinin hash değeridir.
Geçici olarak mümkün olduğunca basit tutuyoruz, böylece inceleme süreci basit ve hızlı olabilir ve OP Stack üzerinde büyük bir fark yaratmaz. Ancak şimdi, taahhütleri toplu işleme veya bunları blob'a gönderme gibi daha ucuz hale getirecek bazı optimizasyonlar var veya farklı yöntemler benimsemek gibi. Bu nedenle, L1 maliyetlerini düşürmek için kesinlikle bunu araştıracağız.
Bu, bizim için oldukça heyecan verici bir durum. Elbette, tüm zincirler arasında etkileşim kurabilmeyi sağlayacak olan tüm birlikte çalışabilirlik ile ilgili içerikleri sabırsızlıkla bekliyoruz. Bunun kullanıcılar için büyük bir ilerleme olacağını anlamak.
Bu işlerin çoğunun kesinlikle sizin tarafınızdan gerçekleştirilmesi gerekiyor. Ancak, bu işlerin Plasma modunda nasıl göründüğünü ve farklı güvenlik varsayımlarına sahip olduğunu anlamak istiyoruz.
Ben: Bu noktaya değinmek gerekirse, bu OP Stack modülerliği için bir başka test olacak. Sen öneriyorsun.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
15 Likes
Reward
15
6
Share
Comment
0/400
YieldHunter
· 08-04 00:52
teknik olarak konuşursak... off-chain veri güvenilirliğinden emin değilim smh
View OriginalReply0
DaoResearcher
· 08-04 00:51
Veri erişilebilirliği üçgeninden türetilen bu fikir harika.
Optimism kurucu ortakları, Plasma Mode geliştiricileri ile OP Stack'in geleceğini tartıştı.
DEVS ON DEVS: tdot ve Ben Jones ile sohbet
"Bu özel Devs on Devs bölümünde, Plasma Mode'un ana protokol geliştiricisi tdot('ı ve aynı zamanda Redstone'un geliştiricisi )'i, ayrıca Optimism'ın kurucu ortağı Ben Jones'u davet ettik. Optimism, OP Stack'in temel itici gücüdür. Plasma Mode, geliştiricilerin OP Stack üzerinde inşa etmelerine olanak tanırken, verileri L1'e yayınlamaları gerekmemektedir; bunun yerine, maliyetleri azaltmak ve ölçeklenebilirliği artırmak için esnek bir şekilde zincir dışı veri sağlayıcılara geçiş yapabilirler. Sohbetlerinde, Redstone ve Optimism iş birliğinin kökenlerini, Plasma'nın yeniden canlandırılmasının önemini, deneysel protokollerin üretim ortamına getirilmesinin gerekliliğini, Plasma Mode ve OP Stack'in gelecekteki yol haritasını ve tüm zincir oyun alanının gelişimine duydukları heyecanı tartıştılar."
Plasma Modunu OP Stack'i Geliştirmek İçin Nasıl Kullanılır
Ben: OP Stack'ı geliştirme süreci nasıl başlıyor?
tdot: Yaklaşık bir yıl önce Lattice'e katıldım ve Plasma Mode'dan sorumluyum. Hedef oldukça net: Birçok MUD uygulamamız var, bunlar büyük miktarda gaz tüketiyor ve aynı zamanda büyük verileri zincire koymaya çalışıyoruz, bu nedenle hem bu ihtiyaçları karşılayabilecek hem de uygun fiyatlı bir çözüme ihtiyacımız var. Lattice ekibi OP Stack üzerinde bazı denemeler yaptı, örneğin bazı zincir üstü dünyaları prototipini oluşturup OP Stack'e dağıttık. OP Stack'in oldukça iyi çalıştığını gördük.
Bu nedenle kendimize sorduk, "Bunu daha ucuz hale nasıl getirebiliriz?" Temel varsayım, "OP Stack'in Ethereum'un felsefesine en uygun ve tamamen EVM ile uyumlu çerçeve olduğunu düşünüyoruz." Ana ağda çalışan şeyler OP Stack'te de çalışabilir, bu ideal bir çözümdür. Ama bunu daha ucuz hale getirmek istiyoruz.
O sırada, calldata hala OP Stack zincirinin veri kullanılabilirliği (DA) kaynağıydı ve bu çok pahalıydı. Bu yüzden, açıkça bir L2 başlatmak için calldata kullanamayız çünkü tam zincir oyunlarımız ve MUD dünyamız daha yüksek bir iş hacmine ihtiyaç duyuyor. Bu nedenle, diğer veri kullanılabilirliği (Alt DA) çözümlerini denemeye karar verdik. Aslında, başlangıçtaki OP Stack belgelerinde Alt DA'yı keşfetmenin önemine zaten değinilmişti.
Bu yüzden kendimize şunu sorduk: "Eğer zincir dışı DA ile başlarsak ne olur?" Tüm güvenlik modelinin ve her şeyin L1 Ethereum'a bağımlı olmasını umuyoruz. Bu nedenle diğer Alt DA çözümlerinden kaçındık ve verileri merkezi DA depolama alanında saklamaya karar verdik, ardından L1 üzerinde etkili bir güvenlik modeli bulmayı hedefledik.
Bu, bazı eski Plasma kavramlarını yeniden kullanmayı ve bunları rollup'un üzerine yerleştirmeyi neden istediğimizdir. Burada bazı farklılıklar var. En büyük soru, mevcut OP Stack üzerinde zincir dışı DA ve zincir içi veri meydan okumasını nasıl gerçekleştireceğimizdir? Amacımız, OP Stack'i mümkün olduğunca az değiştirmek, rollup yolunu etkilememek, çünkü OP Stack'i kullanan diğer rollup zincirlerinin güvenliğini etkilemek istemiyoruz.
Rollup tasarımı yaparken, "Eğer biri veri üretim sürecini değiştirip verileri başka bir yerden saklamak isterse ne olur?" diye düşünmezsiniz. Bu değişiklikler olsa bile, OP Stack hala çok güçlü ve kutudan çıkar çıkmaz harika bir performans sergiliyor. Bu yaptığımız ilk değişiklik.
Sonrasında, bu zorlukları oluşturmak için bir sözleşme yazmamız gerekiyor. Verileri zincire zorla koymak için DA zorlukları var. Bu, sürece sözleşmeyi entegre etmenin ikinci adımıdır. Türetme sürecinde, bütün entegrasyon sistemini inşa etmemiz gerekiyor, böylece bir zincir dışı DA kaynağından ve bir L1 DA zorluk sözleşmesinden veri türetebilirsiniz, böylece veriler zorluk çözüm sürecinde zincire gönderildiğinde.
Bu, meselenin özüdür. Karmaşık çünkü işleri zarif ve sağlam tutmak istiyoruz. Aynı zamanda, bu nispeten basit bir kavram. Her şeyi yeniden icat etmeye veya tüm OP Stack'i değiştirmeye çalışmadık, bunun yerine karmaşık bir ortamda işleri basit tutmaya çalıştık. Yani genel olarak, bu oldukça harika bir mühendislik yolculuğu.
Ben: OP açısından konuşabilirim. Bazı Lattice'in erken çalışmalarından bahsettin. Aynı zamanda, Optimism neredeyse tüm OP Stack'i baştan sona yeniden yazdı, bu sürüme Bedrock adını verdik.
Temelde, rollup'ı inşa ettikten iki yıl sonra, bir adım geri attık ve "Tamam, eğer öğrendiğimiz tüm deneyimleri en üst düzeye çıkarmak istiyorsak, bu nasıl olur?" diye düşündük. Bu, nihayetinde Bedrock olarak adlandırılan kod tabanına dönüştü ve bu, ağımıza yaptığımız en büyük yükseltme.
O zamanlar, sizinle birlikte OPCraft adında bir proje üzerinde çalıştık, bence Biomes onun ruhsal varisidir, bu bizim zincir üzerinde en keyifli oynadığımız zamandı. Aynı zamanda, diğerlerinin de OP Stack kullanarak geliştirme yapabilmesi nedeniyle bir nefes aldık. Son birkaç yıl içinde, ölçeklendirme açısından başka bir önemli dönüm noktasının, birçok kişinin zincir çalıştırabilmesi olduğunu düşünüyorum.
Sadece büyük ve karmaşık kod kütüphaneleri geliştirenlerin bunu yapabileceği anlamına gelmiyor. İşbirliğine başladığımızda, başkalarının bu kod kütüphanesini devralıp harika şeyler yapabildiğini görmek büyük bir onur. Sonra bu durumun gerçek uygulamalarda Plasma'ya genişlediğini görmek gerçekten harika. O tarihle ilgili biraz konuşabilirim.
Optimism, Optimism olmadan önce, aslında Plasma adı verilen bir teknolojiyi araştırıyorduk. O zamanlarda üstlendiğimiz görev, o dönemki ölçeklendirme topluluğunun kapasitesinden çok daha fazlaydı. Erken dönem Plasma tasarımında gördüğünüz tasarım, bugünkü Plasma ile doğrudan bir ilişkiye sahip olmayabilir.
Bugünkü Plasma çok daha basit. Durum doğrulama kanıtlarını ve zorluklarını verinin zorluklarından ayrı olarak ele alıyoruz. Sonuç olarak, birkaç yıl önce Rollup'ların Plasma'dan çok daha basit olduğunu fark ettik. O zaman topluluğun vardığı sonuç "Plasma öldü" idi. Bu, o dönemde Ethereum ölçeklenme tarihinin bir esprisi.
Ama hepimiz "Plasma ölmedi, sadece daha basit bir görevle başlayabiliriz" dedik. Şimdi farklı terimler kullanıyoruz. Örneğin, o zamanlarda ( çıkışları ) gibi kavramlar vardı, şimdi geriye dönüp bakınca "oh, bu bazı ek adımlar içeren bir veri kullanılabilirlik zorluğuydu" diyebilirsiniz. Yani OP Stack'in sadece başkaları tarafından kullanılmadığını, aynı zamanda bizim başlangıçta denediğimiz ama oldukça karmaşık ve olgunlaşmamış bir soyutlama biçimiyle evrildiğini görmek gerçekten harika. Tam bir döngüyü tamamladık, etrafında harika soyutlamalar yaptınız ve bunu mantıklı ve makul bir şekilde çalıştırdınız. Bu gerçekten çok havalı.
En önemli olan, üretim ortamına mümkün olan en kısa sürede geçmektir.
tdot: Plasma modu hala bazı zorluklar ve çözülmemiş sorunlar barındırıyor, bunları çözmek için çalışıyoruz. Anahtar, on yıl süren bir zaman kaybını nasıl önleyeceğimizdir? Ne demek istediğimi anlıyor musun? Sonuç elde edebileceğimiz aşamaya bir an önce ulaşmamız gerekiyor.
Bu bizim düşüncemiz. MUD tabanlı birçok uygulamamız var ve bunları hemen ana ağda başlatmak istiyoruz. Bu oyunlar için mümkün olan en kısa sürede bir ana ağ hazırlamamız gerekiyor. İnsanlar bekliyor ve hazırlar. Tüm bu uygulamaları çalıştırmak için hızlı bir şekilde başlatılabilen ve çalışabilen bir zincire ihtiyacınız var, böylece bu uygulamalar, sorunları çözerken paralel olarak gelişebilir ve daha iyi hale gelebilir. Ar-ge'den üretim istikrarına geçiş uzun zaman alıyor.
Bir şeyi ana ağa çıkarmak, onun izinsiz, sağlam ve güvenli olmasını sağlamak için büyük miktarda zaman harcamak gerekiyor. Bu hedefe ulaşma sürecimizi görmek gerçekten etkileyici. Bu yüzden yüksek düzeyde çevik kalmamız gerekiyor çünkü çok fazla şey var. Tüm ekosistem çok hızlı gelişiyor. Herkesin büyük miktarda yenilik sunduğunu düşünüyorum. Bu yüzden ayak uydurmalısınız, ancak güvenlik ve performansta da taviz verememelisiniz, aksi takdirde sistem çalışamaz.
Ben: Ya da teknik yük demek. Bahsettiğin en az değişiklik ilkesi, Bedrock yeniden yazımımızın temel ilkelerinden biri. Uçtan uca yeniden yazımı konuştum, ama daha da önemlisi, yaklaşık 50,000 satır kodu azalttık, bu başlı başına çok güçlü. Çünkü haklısın, bu işler gerçekten zor.
Her bir kod satırı eklemek, sizi üretim ortamından daha da uzaklaştırır, işlerin gerçek testlerden geçmesini zorlaştırır ve daha fazla hata fırsatı getirir. Bu nedenle, bu süreci ilerletme konusundaki tüm çabalarınız için özellikle OP Stack'in yeni operasyonel modeli için yaptığınız katkılara çok teşekkür ederiz.
tdot: OP Stack gerçekten bu tür şeylerde hızlı ilerlemenizi sağlayan bir yol yarattı. Herkesi koordine etmek çok zor çünkü açıkça iki farklı şirketiz. Lattice'de bir oyun, bir oyun motoru ve bir zincir inşa ediyoruz.
Ve siz yüzlerce, binlerce şey inşa ediyorsunuz ve bu ürünlerin hepsini düzenli olarak teslim ediyorsunuz. Koordinasyon açısından bu gerçekten çok zor.
Ben: Evet, gerçekten daha kat edecek çok yol var. Ama bu, modülerliğin çekici olmasının temel nedenlerinden biri. Benim için, OP Stack açısından bakıldığında, bu en heyecan verici şeylerden biri, Redstone üzerinde inşa edilen o muhteşem oyunlar ve sanal dünyaları bir kenara bırakırsak. Sadece OP Stack açısından bakıldığında, bu çok güçlü bir örnek; birçok harika ana geliştiricinin buraya katıldığını ve bu yığın üzerinde iyileştirmeler yaptığını kanıtlıyor, bu gerçekten harika.
Bu ilk sefer, bir anahtar Boolean değeri ile sistemin özelliklerini önemli ölçüde değiştirebilirsiniz. Bunu tamamen başarmak, belirttiğin gibi, gerçekten uzun bir yol var. Ama bunun neredeyse etkili bir şekilde yapılabilmesi için modüler desteğe ihtiyaç var, değil mi? Bizim için, bunun gibi L2 Geth'i yeniden yazmadan başardığınızı görmek gerçekten rahatlatıcı. Bu benim için modülerliğin işe yaradığını kanıtlıyor.
tdot: Şu anda durum daha iyiye gitti. Bu örneğe bakıldığında, her şeyi bağımsız küçük modüllere dönüştürdünüz, ayarlanabilir ve özellikleri değiştirilebilir. Bu yüzden hangi yeni özelliklerin entegre edileceğini görmek için çok heyecanlıyım. Hatırlıyorum da, endişelendiğimiz şey, OP Stack'teki tüm değişiklikleri içeren bir fork'umuzun olmasıydı ve bunun ana kısma birleştirilmesi gerekiyordu. O zaman "Aman Tanrım, her şeyi gözden geçirmek çılgınca olacak" diye düşündük.
Bunu daha küçük parçalara ayırmak zorunda kaldık, ancak tüm süreç oldukça sorunsuz geçti. Takımla işbirliği ortamımız çok iyiydi, bu yüzden inceleme süreci de oldukça keyifliydi. Bu çok doğal hissettiriyordu. Ayrıca, bazı potansiyel sorunları inceleme ve çözme konusunda bu sürecin oldukça hızlı ilerlediğini düşünüyorum. Her şey beklenmedik şekilde sorunsuz geçti.
Ben: Bu gerçekten harika. Bu yılki önceliklerimizden biri OP Stack için katkı yolları oluşturmak. Bu süreçlere katıldığınız için çok teşekkür ederim. Bu süreçlerin katlanılmaz olmadığını ve bazı sonuçlar elde ettiğimizi duyduğuma sevindim. Bu noktada, senin bakış açına göre, bu çalışmanın nasıl gelişeceğini merak ediyorum? Gelecekte en çok hangi geliştirmeyi bekliyorsun?
tdot: Farklı iş yönleri var. Temelde arıza kanıtlama mekanizmasının entegrasyonu ile ilgilidir. Tüm teknik yığınları merkeziyetsizleştirmek ve izin gerektirmeyen özelliklerini artırmak için kademeli bir yaklaşım benimsiyoruz; nihai hedef, izin gerektirmeyen ve zorunlu çıkış gibi işlevleri gerçekleştirmektir.
Bu nihai amacımız var ve güvenliği sağlarken bunu kademeli olarak gerçekleştirmekteyiz. Bir zorluk, bazen ana ağa geçmemek daha kolaydır çünkü böylece sert çatal yapmaya gerek kalmaz. "Ah, her şey tamamen hazır olana kadar yayınlamayı beklersem, böylece sert çatal yapmam gerekmeyecek ve teknik bir yüküm de olmayacak" diye düşünebilirsiniz. Ancak, ana ağda hızlı bir şekilde çevrimiçi olmak istiyorsanız, bu karmaşık yükseltmeleri ele almalı ve sık sık yayın yapmalısınız. Bunu başarmak ve yüksek kullanılabilirliği korumak her zaman bir zorluktur.
Arıza kanıtı mekanizması ve tüm bu parçalar hazır olduğunda, Plasma modeli açısından birçok yükseltme olacağını düşünüyorum. Toplu taahhütlerin sunulması konusunda hala bazı optimizasyon fırsatları olduğunu düşünüyorum. Şu anda her işlem için bir taahhüt ile basit bir şekilde yapıyoruz. Ve taahhüt, yalnızca zincir dışı depolanan girdi verilerinin hash değeridir.
Geçici olarak mümkün olduğunca basit tutuyoruz, böylece inceleme süreci basit ve hızlı olabilir ve OP Stack üzerinde büyük bir fark yaratmaz. Ancak şimdi, taahhütleri toplu işleme veya bunları blob'a gönderme gibi daha ucuz hale getirecek bazı optimizasyonlar var veya farklı yöntemler benimsemek gibi. Bu nedenle, L1 maliyetlerini düşürmek için kesinlikle bunu araştıracağız.
Bu, bizim için oldukça heyecan verici bir durum. Elbette, tüm zincirler arasında etkileşim kurabilmeyi sağlayacak olan tüm birlikte çalışabilirlik ile ilgili içerikleri sabırsızlıkla bekliyoruz. Bunun kullanıcılar için büyük bir ilerleme olacağını anlamak.
Bu işlerin çoğunun kesinlikle sizin tarafınızdan gerçekleştirilmesi gerekiyor. Ancak, bu işlerin Plasma modunda nasıl göründüğünü ve farklı güvenlik varsayımlarına sahip olduğunu anlamak istiyoruz.
Ben: Bu noktaya değinmek gerekirse, bu OP Stack modülerliği için bir başka test olacak. Sen öneriyorsun.