Teknik açıdan Parity'nin temel geliştiricisi Kian Paimani'nin Polkadot ekosistemine yeni bir ölçeklenebilirlik getirmek için nasıl JAM protokolünü açıkladığına ilişkin bir yorumu, JAM'ın nasıl çalıştığına daha iyi bir anlayış sağlamak için.
Yazan: Kian Paimani, Parity Core Developer
Derleme: Polkadot Labs
'Polkadot Bilgi Haritası', Polkadot'a giriş seviyesinde bir makaledir. Polkadot'un en temel kısımlarından başlayarak, Polkadot hakkında tam bir anlayış sağlamak için çalışıyoruz. Tabii ki bu büyük bir projedir ve dolu dolu zorluklarla doludur. Ancak, bu çabalarımızla Polkadot'un doğru bir şekilde tanınmasını ve Polkadot hakkında bilgisi olmayan insanların Polkadot ile ilgili bilgileri kolayca ve hızlı bir şekilde öğrenmelerini umuyoruz. Bugün bu bölümün 148. sayısıdır ve bu makale, Parity'nin ana geliştiricisi Kian Paimani tarafından Polkadot'un en yeni JAM protokolünü teknik açıdan açıklamak için yazılmıştır. Bu makale, yazarın birinci şahıs bakış açısıyla yazılmıştır.
*Polkadot1、Polkadot2 ve bunların JAM'a nasıl dönüştüğünün ayrıntılı açıklaması aşağıda verilmiştir. (Detaylar için bkz: ***) Bu makale, özellikle Polkadot'a çok aşina olmayan ancak blok zinciri sistemleri hakkında bazı bilgileri olan teknik personel ve diğer ekosistemle ilgili teknolojileri bilen okuyucular için hazırlanmıştır.
Benim düşünceme göre, JAM beyaz kağıdını okumadan önce bu metni okumak iyi bir başlangıçtır. (Detaylar için bkz:**)
Arka Plan Bilgisi
Bu metin, okuyucunun aşağıdaki kavramlara aşina olduğunu varsayar.
Blok Zinciri bir durum geçiş fonksiyonu olarak tanımlanabilir.
“Durum”ın ne olduğunu anlama. (Detaylar için bkz: _sdk_docs/reference_docs/blockchain_state_machines/index.html)
Ekonomik güvenlik ve Proof of Stake.(Detaylar için bkz:、)
Önsöz: Polkadot1
Öncelikle, Polkadot1'in en yenilikçi özelliklerini düşünecek olursak.
Sosyal Düzey:
Polkadot, büyük bir Merkezi Olmayan Özerk Organizasyon (DAO) olan bir ağdır. Bu ağ, Merkeziyetsizlik üzerine kurulu olup, kendini yürüten yönetim dahil olmak üzere tamamen on-chain temelli bir yönetişimi gerçekleştirir ve çatal gerektirmeyen çalışma zamanı yükseltmelerini sağlar.
Amerika Birleşik Devletleri Menkul Kıymetler ve Borsa Komisyonu (SEC), DOT'yi bir yazılım olarak değerlendirirken bir menkul kıymet olarak değil. (Detaylar için bkz.: )
Polkadot paylaşılan güvenlik ve Parçalama yürütme sağlar.
WASM tabanlı bir protokol kullanarak (ayrıntılar için bkz: _sdk_docs/reference_docs/wasm_meta_protocol/index.html), blok zincirinin kodunu bayt kodu olarak durumda depolar. Bu, çoğu yükseltmenin çatal gerektirmeden ve heterojen parçalama sağlanarak gerçekleştirilebileceği anlamına gelir.
「异构Parçalama」hakkında daha fazla bilgi için ilgili bölüme bakın.
Parça Yürütme: Önemli Çıkarımlar
Şu anda, Polkadot ve Ethereum gibi diğer Layer2 'blockchain' ağlarını barındıran bir Layer1 ağı tartışıyoruz. Bu nedenle, Layer2 ve Parachain terimleri birbirinin yerine kullanılabilir.
Blok zincirinin ölçeklenebilirliğinin temel sorunu şu şekilde formüle edilebilir: Proof of Stake'in (Proof-of-Stake) kripto ekonomisi aracılığıyla belirli kodların yürütülmesinin güvenilir olmasını sağlayabilecek bir grup doğrulayıcılar vardır. Varsayılan olarak, bu doğrulayıcıların birbirlerinin tüm işlerini yeniden gerçekleştirmeleri gerekir. Bu nedenle, tüm doğrulayıcıları her zaman her şeyi yeniden yürütmeye zorladığımız sürece, tüm sistem ölçeklenebilir değildir.
Lütfen dikkat edin, yukarıdaki mutlak yeniden yürütme prensibi değişmezse, bu modelde doğrulayıcılarının sayısını artırmak aslında sistemdeki verimliliği artırmayacaktır.
Yukarıda gösterilen, ParçalamaBlok zinciriyle karşılaştırıldığında bir tekil Blok zinciridir. Tüm ağ doğrulayıcıları girişi (yani Blok) sırayla işleyecektir.
Bu tür bir sistemde, Layer1 daha fazla Layer2 barındırmak istediğinde, doğrulayıcıların tümü şimdi tüm Layer2 işlerini yeniden yürütmek zorunda kalır. Açıkçası, bu yöntem ölçeklendirilemez. Optimistik Rolluplar, sadece biri dolandırma iddiasında bulunduğunda yeniden yürütülür (dolandırıcılık kanıtı). SNARK tabanlı Rolluplar, SNARK kanıtını doğrulamanın bunu oluşturmaktan çok daha düşük maliyetli olduğu gerçeği üzerinden bu sorunu atlatır, bu nedenle tüm doğrulayıcıların SNARK kanıtını doğrulamasına izin verir. Bu konuda daha fazla bilgi için "Ek: Ölçeklenebilirlik Uzay Haritası"na bakın.
Parçalamanın basit bir çözümü, doğrulayıcılar kümesini daha küçük alt kümeler halinde bölmek ve bu daha küçük alt kümeyle Layer2 Blok'ları yeniden yürütmelerine izin vermektir. Bu yöntemin sorunu nedir? Ağı ve ekonomik güvenliği parçalıyoruz. Layer2'nin güvenliği Layer1'in altında ve doğrulayıcılar kümesini daha fazla parçaladıkça güvenlik daha da düşecektir.
Optimistik Rollup'ların her zaman yeniden yürütme maliyeti olmadığına karşın, Polkadot Parçalama'yı tasarımında düşünerek bir kısmı doğrulayıcıların Layer2 Blokunu yeniden yürütmesine olanak tanır ve aynı zamanda tüm ağ katılımcılarına Layer2 Blokunun gerçekliğini ve doğrulayıcılar kümesinin onu yeniden yürüttüğünde olduğu kadar güvenli olduğunu kanıtlayan yeterli Crypto ekonomi kanıtı sağlar. Bu, yeni ve yenilikçi (yakın zamanda resmi olarak yayınlanan) ELVES mekanizmasıyla gerçekleştirilir. (Detaylar için bkz.:)
Kısacası, ELVES, bir tür 'şüpheci rollups' mekanizması olarak görülebilir. Birkaç tur doğrulayıcılar, belirli bir Layer2 Blok'un geçerliliğini diğer doğrulayıcılar aktif olarak sorgulayarak, bu Layer2 Blok'un geçerliliğini büyük olasılıkla doğrulayabiliriz. Aslında, herhangi bir anlaşmazlık durumunda, tüm doğrulayıcılar topluluğunun hızla katılmasını gerektirecektir. Polkadot'un kurucu ortağı Rob Habermeier, bu konuyu detaylı bir şekilde açıklayan bir makalede bu noktayı açıklamıştır. (Detaylar için bkz.: )
ELVES, Polkadot'un ölçeklenebilirlik açısından ana teknik başarısı olan, Polkadot'a önceki olarak karşılıklı dışlanan iki özelliği aynı anda sağlayan 'Parçalama Yürütme' ve 'Paylaşılan Güvenlik' özelliklerini kazandırır.
Şimdi, 'CORE' benzetmesini tartışmaya devam edelim.
Parçalama'yı yürüten bir blok zinciri, bir CPU'ya çok benzer: CPU'nun talimatları paralel olarak yürüten birden fazla çekirdeğe sahip olması gibi, Polkadot da Katman 2 bloklarını paralel olarak işleyebilir. Bu nedenle Polkadot üzerindeki Katman 2'ye parachain denir ve tek bir Katman 2 bloğunun doğrulayıcıların daha küçük bir alt kümesi tarafından yeniden yürütüldüğü ortama "çekirdek" denir. Her bir çekirdek "birlikte çalışan bir dizi doğrulayıcılar" olarak soyutlanabilir.
Tekil Blok zincirini, herhangi bir zaman diliminde yalnızca bir Blok'un alındığı şeklinde düşünebilirsiniz, ancak Polkadot, her zaman diliminde bir Rol zinciri Blok ve her bir çekirdek için bir paralel zincir Blok alır.
Heterojenlik
Şu ana kadar, sadece ölçeklenebilirlik ve Polkadot tarafından sağlanan Parçalama yürütmesini tartıştık. Dikkat edilmesi gereken nokta, Polkadot'un her Parçalama'nın aslında tamamen farklı bir uygulama olduğudur. Bu, bytcode içinde depolanmış bir meta protokol kullanılarak gerçekleştirilir: Blok zinciri tanımını Blok zinciri kendi durumunda bytcode olarak depolayan bir protokol. Polkadot 1.0'da WASM tercih edilen bytcode olarak kullanılırken, JAM'da PVM/RISC-V kullanılmıştır.
Sonuç olarak, işte Polkadot'un heterojen parçalı blokzinciri olarak adlandırılmasının nedeni budur. (Ayrıntılar için bkz: ) Her Layer2 tamamen farklı bir uygulamadır.
Polkadot2
Polkadot2'nin önemli bir parçası, çekirdeğin kullanımını daha esnek hale getirmektir. Orijinal Polkadot modelinde, çekirdek 6 aydan 2 yıla kadar herhangi bir süre için kiralanabilirdi, bu da iyi kaynaklara sahip işletmeler için uygundu, ancak küçük ekipler için o kadar iyi değildi. Polkadot Core'un daha esnek bir şekilde kullanılabilen özelliği "Agile CoreTime" olarak adlandırılıyor. Bu modda Polkadot Core, uzun süreli kiralamak isteyenler için tavan fiyat garantisi ile bir blok kadar kısa veya bir ay kadar uzun bir süre için kiralanabilir.
Polkadot 2'nin diğer özellikleri, tartıştığımız süreçte yavaş yavaş ortaya çıkıyor, bu nedenle burada fazla detaya gerek yok.
Core İç ve On-chain İşlemleri
JAM'ı anlamak için öncelikle bir Layer2 Blok'un Polkadot çekirdeğine nasıl girdiğini anlamak gerekmektedir.
Aşağıdaki içerik büyük ölçüde basitleştirilmiştir.
Gelin bir göz atalım, çekirdek aslında bir grup doğrulayıcılar tarafından oluşturulur. Bu nedenle, 'veriler çekirdeğe gönderildiğinde' ifadesi aslında bu verilerin bu grup doğrulayıcılara iletilmesi anlamına gelir.
Bir Layer2 Blok, Layer2'nin bir kısmıyla birlikte çekirdeğe gönderilir. Bu veriler, Layer2 Blok'un yürütülmesi için gereken tüm bilgileri içerir.
Bazı doğrulayıcılar Core içindeki Layer2 Blok'u yeniden çalıştırır ve Konsensüs ile ilişkili görevleri devam ettirir.
Core doğrulayıcılar, gerekli verileri diğer doğrulayıcılar (çekirdek dışı doğrulayıcılar) için yeniden yürütmeleri için sağlayacak. Diğer doğrulayıcılar, bu Layer2 Blok'un yeniden yürütülüp yürütülmeyeceğine ELVES kurallarına göre karar verebilir ve bu işlemi tamamlamak için bu verilere ihtiyaç duyarlar.
Dikkat edin, şu ana kadar tüm işlemler Polkadot'un ana blok ve durum geçiş fonksiyonları dışında gerçekleştirilmiştir. Her şey çekirdek içinde ve veri erişilebilirlik katmanında gerçekleşir.
Sonunda, Layer2'nin en son durumunun küçük bir kısmı Polkadot ana iletim zincirinde görülebilir. Önceki tüm işlemlerden farklı olarak, bu işlem Layer2 Blok'un yeniden gerçekleştirilmesinden çok daha ucuzdur. Polkadot'un ana durumunu etkiler, Polkadot Blok'ta görülebilir ve tüm Polkadot doğrulayıcılar tarafından yürütülür.
Yukarıdaki içerikten, Polkadot'un gerçekleştirdiği bazı işlemleri tartışabiliriz:
Öncelikle, 1. adımdan çıkarıyoruz ki Polkadot'ta geleneksel blok zinciri durum dönüşüm fonksiyonundan farklı bir yeni yürütme yöntemi bulunmaktadır. Genellikle, ağdaki tüm doğrulayıcılar bir işlem gerçekleştirdiğinde ana blok zinciri durumu güncellenir. Bu durumu on-chain işlem olarak adlandırıyoruz, bu 3. adımda olur. Ancak, çekirdek içinde gerçekleşen durum (1. adım) bundan farklıdır. Bu yeni tür blok zinciri hesaplamasına çekirdek içi yürütme denir.
Sonra, 2. noktadan itibaren Polkadot'un yerleşik bir veri kullanılabilirliği (Data-Availability, kısaca DA) katmanı sağladığını ve Layer2'nin bunu otomatik olarak kullanarak performans kanıtlarının belirli bir süre boyunca kullanılabilir olduğunu çıkarabiliriz. Bununla birlikte, DA katmanına yayınlanabilen veri blokları sabittir ve her zaman Layer2 Blok'un yeniden yürütülmesi için gerekli olan kanıtları içerir. Dahası, parachain kodu hiçbir zaman DA katmanı verisini okumaz.
Yukarıdaki metni anlamak, JAM'ın temelini anlamak demektir. Özetle:
CORE içinde yürütme (in-core ution): Çekirdek içinde gerçekleşen işlemi ifade eder. Zengin, genişletilebilir ve Crypto ekonomisi ve ELVES aracılığıyla on-chain yürütme ile aynı güvenliği sağlar.
on-chain uygulama (on-chain execution): doğrulayıcıların yaptığı işlemleri ifade eder. Ekonomik güvenceye dayalı olarak, doğrulayıcılar varsayılan olarak güvenliği sağlar, ancak maliyeti daha yüksek ve daha fazla kısıtlama vardır çünkü herkes tüm işlemleri gerçekleştirir.
Önceki kısmın anlamını tam olarak anladığınızda, JAM'ın tanıtımına sorunsuz bir şekilde geçebiliriz.
JAM, Polkadot'tan ilham alan ve tamamen uyumlu olan yeni bir protokoldür. Amacı, Polkadot'ın relay chain'ini değiştirmek ve merkezi olmayan ve sınırsız bir şekilde temel kullanımı sağlamaktır.
JAM, Polkadot2 üzerine inşa edilmiştir ve Polkadot'un çekirdeğine erişimi daha da kolaylaştırmayı amaçlamaktadır, ancak agile-coretime'dan daha esnek ve sabit bir kısıtlama olmadan.
Polkadot2, Layer2'nin çekirdekte daha esnek bir şekilde dağıtılmasını sağlar.
JAM, herhangi bir uygulamanın Polkadot'un merkezine dağıtılmasını sağlamayı amaçlar, hatta bu uygulamalar blok zinciri veya Katman2 gibi olmayabilir.
Bu, önceden tartışılan üç temel özgün kavramı geliştiricilere açığa çıkararak gerçekleştirilir: zincir üstünde yürütme, çekirdek içinde yürütme ve DA katmanı.
Başka bir deyişle, JAM'de geliştiriciler şunlara erişebilir:
Tamamen Programlanabilirlik haline getirilmiş çekirdek içi ve on-chain çalışmaları.
Polkadot'un DA katmanına herhangi bir verinin okunup yazılmasına izin verilir.
Bu, JAM hedefinin temel bir açıklamasıdır. Fazla söze gerek yok, burada birçok basitleştirme yapıldı ve protokol hala evrilebilir.
Bu temel anlayışla, şimdi JAM'ın bazı ayrıntılarını daha da tartışabiliriz.
1 Hizmet ve İş Kalemleri
JAM bağlamında, eskiden Layer2/parachain olarak adlandırılan şey artık "Hizmet" olarak adlandırılıyor ve eskiden Blok/İşlem olarak adlandırılan şey artık "İş Öğesi" veya "İş Paketi" olarak adlandırılıyor. Özellikle, bir iş öğesi bir hizmete aittir ve bir iş paketi bir iş öğeleri koleksiyonudur. Bu terimler, Blok Chain/Layer 2'nin ötesinde çok çeşitli kullanım durumlarını kapsayacak kadar genel olacak şekilde kasıtlı olarak tasarlanmıştır.
Bir hizmet, fn refine() ve fn accumulate() olmak üzere üç giriş noktası ile tanımlanmıştır. İlk ikisi hizmetin çekirdek içinde yürütülen içeriği tanımlarken, ikincisi hizmetin on-chain'de yürütülen içeriğini tanımlar.
Son olarak, iki giriş noktasının adı da protokolün JAM (Join Accumulate Machine) olarak adlandırılmasının nedenidir. Join, yani fn refine(), Polkadot çekirdeklerinin farklı hizmetlerin yoğun çalışmasını eşzamanlı olarak işlediği bir aşama olan bu aşamaya denir. Veriler filtrelenir ve bir sonraki aşamaya geçer. Accumulate ise tüm yukarıdaki sonuçların ana JAM durumuna birikmesini ifade eder, yani on-chain yürütme bölümüdür.
İş öğeleri, bir çekirdek içinde, on-chain olarak hangi kodların yürütüleceği kesin olarak belirtilebilir ve içeriklerini nasıl / ne zaman / nereden okuyup yazacakları dağıtılmış veri gölünden (Distributed Data Lake) açıkça belirtilir.
2 Yarı Uyumlu
XCM hakkında mevcut bilgilere göz attığınızda (Polkadot'un seçtiği parachain iletişim dili), tüm iletişimin asenkron olduğunu göreceksiniz. Yani, mesaj gönderildikten sonra cevabını bekleyemezsiniz. (Detaylar için bkz: )
Asenkronlık, sistem tutarsızlığının bir göstergesi olup, sürekli Parçalama sistemleri (örneğin Polkadot 1 ve Polkadot 2 ve mevcut Ethereum Layer2 ekosistemi) için ana dezavantajdır.
Ancak, ancak Whitepaper'ın 2.4 bölümünde açıklandığı gibi, her zaman tüm kiracıları için tam olarak senkronize olan tamamen tutarlı bir sistem, yaygınlık, erişilebilirlik veya esneklikten ödün vermeden belirli bir düzeye kadar yükseliş gösterebilir. (Detaylar için bkz: )
Senkron ≈ Uygunluk || Asenkron ≈ Uyumsuzluk
Bu aynı zamanda JAM'ın öne çıktığı bir başka alandır: JAM, çeşitli özellikleri tanıtarak yeni bir ara durum olan yarı tutarlı bir sistem sağlar. Bu sistemde, sık iletişim kuran alt sistemler, genel sistemde tutarlılığı zorlamadan birbirleri arasında tutarlı bir ortam yaratabilir. Bu, beyaz kağıt yazarı Dr. Gavin Wood'un röportajında en iyi şekilde açıklanmıştır: (Ayrıntılar için bkz: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Başka bir anlayış şekli, Polkadot/JAM'ın bir Parçalama sistemi olarak görülmesidir, bu Parçalama'ların sınırlarının akıcı ve dinamik olarak belirlendiği anlamına gelir.
波卡一直是Parçalama的，并且完全异质化。
Şimdi, bu, Parçalama, heterojen olacak ve bu Parçalama'ların sınırları esnek bir şekilde belirlenebilecek, Gavin Wood'un Twitter'da dediği gibi "yarı tutarlı" sistem. (Detaylar için bkz: _src=twsrc%5Etfw、)
Bu mümkün kılan özellikler şunlardır:
Farklı hizmetlerin sadece aynı çekirdek içinde ve belirli bir Blok içinde olan diğer hizmetlerle senkronize olarak etkileşime girebildiği, durumsuz ve paralel çekirdek içi yürütmeyle birlikte, tüm çekirdekler arası hizmet sonuçlarına erişebilen on-chain yürütme.
2.JAM, herhangi bir belirli hizmet planlamasını zorunlu kılmaz. Sık iletişim gerektiren hizmetler, sıralayıcılarına ekonomik teşvik sağlayarak, bu sık iletişim gerektiren hizmetleri içeren iş paketleri oluşturabilir. Bu, bu hizmetlerin aynı çekirdek içinde çalışmasını sağlar ve birbirleriyle iletişim, bir senkronizasyon ortamında gerçekleştirilen gibi olur.
Ayrıca, JAM hizmeti DA katmanına erişebilir ve bunu geçici ama son derece ucuz bir Veri Katmanı olarak kullanabilir. Veriler bir kez DA'ya yerleştirildiğinde, sonunda tüm çekirdeklere yayılacak, ancak aynı çekirdek içinde hemen kullanılabilir hale gelecektir. Bu nedenle, JAM hizmeti, kendini aynı çekirdeğe sürekli olarak planlayarak daha yüksek bir veri erişim düzeyinden faydalanabilir.
Dikkat edilmesi gereken nokta, yukarıdaki içerik JAM'de mümkün olsa da, protokol katmanında zorunlu olarak uygulanmamıştır. Bu nedenle, bazı arabirimlerin teorik olarak asenkron olduğu ancak sofistike bir soyutlama ve teşvik önlemleriyle pratikte senkron olarak görünebildiği beklenmektedir. Aşağıdaki bölümde tartışılacak olan CorePlay tam da böyle bir örnektir.
3 CorePlay
Bu bölüm, JAM ortamında bir deneysel fikir olarak tanımlanabilen ve yeni bir akıllı sözleşme programlama modeli olarak tanımlanabilen CorePlay'i tanıtır. Bu yazı yazılırken, CorePlay hala ayrıntılı olarak açıklanmamış bir fikirdir.
CorePlay'yi anlamak için öncelikle JAM'ın seçtiği Sanal Makine olan PVM'i tanıtmamız gerekiyor.
4 PVM
PVM, JAM ve CorePlay'in önemli bir ayrıntısıdır. PVM'nin düşük seviye ayrıntıları bu makalenin kapsamının ötesindedir, en iyisi alan uzmanlarının beyaz kitapta açıklamalarına bakmaktır. Bununla birlikte, bu makalenin ihtiyaçları doğrultusunda, sadece PVM'nin bazı özelliklerini açıklamamız yeterlidir:
Verimli ölçüm
Durdurma ve devam etme yeteneği
Latter, CorePlay için özellikle önemlidir.
CorePlay, JAM kullanarak esnek bir dil oluşturmak için bir örnek oluşturuyor, senkronize ve ölçeklenebilir akıllı sözleşme ortamı, çok esnek bir programlama arayüzüne sahip. CorePlay, Actor tabanlı akıllı sözleşmelerin doğrudan JAM çekirdeğine dağıtılmasını önermektedir, böylece onlar senkronize programlama arayüzünden yararlanabilir, burada normal fn main() gibi yazılıp let_result=other_coreplay_actor(data).await? ile iletişim kurulabilir. Eğer other_coreplay_actor aynı JAM Blok içindeki çekirdekte ise, bu çağrı senkroniktir; eğer farklı bir çekirdekte ise, bu Actor durdurulur ve sonraki JAM Blok'ta devam eder. Bu durum, JAM servisleri ve esnek planlaması ile PVM özellikleri sayesinde mümkün hale gelir.
5 CoreChains Hizmet
Son olarak, JAM'ın Polkadot'a tamamen uyumlu olmasının ana nedenlerini özetleyelim. Polkadot'un ana ürünü, çevik temel zamanlı çalışan parachain'lerdir (Parachains), ve bu ürün JAM'da devam ettirilir.
JAM'da en erken dağıtılan hizmetlerden biri, CoreChains veya Parachains olarak adlandırılabilir. Bu hizmet, mevcut Polkadot -2 tarzı parachains'in JAM'da çalışmasına izin verecektir.
Daha fazla hizmet JAM'da dağıtılabilir ve mevcut CoreChains hizmetleriyle iletişim kurabilir, ancak Polkadot'un mevcut ürünleri güçlü kalacak ve yalnızca mevcut Parachain takımlarına yeni kapılar açacak.
Ek: Veri Parçalama
Bu makale, ölçeklenebilirlik açısından Parçalama yürütme perspektifinden çoğunlukla ele alınan içeriği tartışmaktadır. Aynı sorunu veri açısından da ele alabiliriz. İlginç olan, bu durumun yarı tutarlılık durumuyla benzerlik gösterdiğini bulmamızdır: İlkeler olarak, tamamen tutarlı bir sistem daha iyidir ancak ölçeklendirilemez; tamamen tutarsız bir sistem ölçeklendirilebilir ancak ideal değildir ve JAM, yarı tutarlılık modeliyle yeni bir olasılık sunar.
Tamamen Uyumlu Sistem: Bu, Solana gibi tamamen senkronize Akıllı Sözleşme platformunda veya yalnızca ETH Layer1'de dağıtılan cesur platformlarda gördüğümüz bir özelliktir. Tüm uygulama verileri on-chain'de depolanır ve tüm diğer uygulamalara kolayca erişilebilir. Bu, programlanabilir mükemmel bir özelliktir, ancak ölçeklenebilir değildir.
Tutarlı Olmayan Sistem：Uygulama verileri Layer1 dışında ve farklı, izole Parçalama'ların içinde saklanır. Son derece ölçeklenebilir, ancak kombinasyon açısından zayıf bir performans sergiler. Polkadot ve Ethereum'un Rollup modeli bu duruma örnektir.
JAM, yukarıda bahsedilen iki işlevi sağlamanın yanı sıra, geliştiricilere JAM DA katmanına herhangi bir veriyi yayınlama izni verir; bu, bir anlamda on-chain veri ve off-chain veri arasındaki orta noktadır. DA katmanını kullanan yeni türde uygulamaları yazabilir ve sadece mutlak önemli verileri JAM durumuna kalıcı olarak kaydedebilirsiniz.
Ek: Ölçeklenebilirlik Alanı Haritası
Bu bölüm, blok zinciri ölçeklenebilirlik alanındaki görüşümüzü yeniden açıkladı. Bu, beyaz kağıtta da açıklandığı gibi, burada daha özlü bir versiyon sunulmaktadır.
Blockchain'un ölçeklenebilirliği büyük ölçüde geleneksel dağıtık sistemlerde kullanılan yöntemleri izler: yukarı doğru ölçeklendirme (dikey) ve dışarı doğru ölçeklendirme (yatay).
Yukarı doğru genişleme, Solana gibi platformlar tarafından yapılan bir çalışmadır. Maksimum işlem hacmini elde etmek için kod ve donanımın sınırlarını optimize eder.
Dışa doğru genişleme, Ethereum ve Polkadot'un benimsediği bir stratejidir: herkesin yapması gereken iş miktarını azaltmak. Geleneksel dağıtık sistemlerde, bunun için daha fazla kopya makine eklenerek gerçekleştirilir. Blok zinciri içinde, 'bilgisayarlar', tüm ağın doğrulayıcılar topluluğudur. Onların arasında iş paylaşımı yaparak (ELVES'in yaptığı gibi) veya umut verici rollups'un sorumluluklarını azaltarak, doğrulayıcılar topluluğunun iş yükünü azaltarak sistem genişlemesini gerçekleştirdik.
Blok zincirinde, dışarı doğru genişleme, tüm işlemleri yürütme ihtiyacını azaltmak için gerekli makine sayısını azaltmaya benzer.
Aşağıda özetlenmiştir:
Yükseltme: Yüksek performanslı donanım + tekil blok zincirinin optimizasyonu.
Dışa genişleyin:
Optimist Rollups
SNARK tabanlı rollups
ELVES：波卡的讽刺 Rollups（Cynical Rollups）
Ek: Aynı donanım, çekirdek güncellemesi
Bu bölüm, Rob Habermeier'in Sub02023'teki benzetmesine dayanarak: Polkadot: Çekirdek/Kullanıcı Alanı|Sub02023-YouTube (ayrıntılar için bkz.:), Polkadot'un yükseltmesi olarak JAM'ı gösteriyor: Aynı donanımda çekirdek güncellemeleri.
Tipik bir bilgisayarda, tüm yığını üç bölüme ayırabiliriz:
Donanım
Çekirdek
Kullanıcı Alanı
Polkadot'ta, donanım, hesaplama ve veri erişilebilirliği sağlayan temel bir özellik olmuştur, yukarıda belirtildiği gibi.
Polkadot'ta çekirdek aslında[9]Şu ana kadar iki bölüm içerir:
1.parachain (Parachains) protokol: bir görüşleme, çekirdek kullanımı için sabit bir yöntem.
Bir dizi temel fonksiyon, örneğin DOT Token ve transferlenebilirliği, Stake, yönetişim vb.
Bu ikisi de Polkadot'un Orta Aktarma Zinciri (Relay Chain) üzerinde mevcuttur.
Kullanıcı alan uygulamaları, parachains'in örnekleridir, bunların yerli Token'ları ve üzerlerine inşa edilen diğer içerikleri.
Bu süreci aşağıdaki gibi görselleştirebiliriz:
Polka her zaman daha fazla temel işlevi parachain adlı benzersiz bir kullanıcıya taşımayı düşünmüştür. Bu, Minimal Röle RFC'nin gerçekleştirmeyi amaçladığı hedefdir. (Ayrıntılar için bkz: )
Bu, Polkadot ağının sadece parachainprotokol sağlayan paralel bir zincirle ilgilendiği anlamına gelir ve bu da çekirdek alanını kısmen daraltır.
Bu mimari bir kez gerçekleştirildiğinde, JAM göçünün nasıl görüneceğini daha kolay görselleştirmek mümkün olacaktır. JAM, Polkadot'un çekirdek alanını büyük ölçüde daraltacak ve daha genel kullanıma uygun hale getirecektir. Ayrıca, Parachains protokolü, aynı çekirdek (donanım) ve çekirdek (JAM) üzerinde uygulama yazmanın az sayıdaki yollarından biri olduğu için kullanıcı alanına taşınacaktır.
Bu aynı zamanda JAM'ın sadece Polkadot röle zincirinin yerine geçen bir şey olduğunu, parachain'in yerine geçmediğini açıkça gösteriyor.
Başka bir deyişle, JAM göçünü bir çekirdek yükseltme olarak düşünebiliriz. Temel donanım aynı kalırken, eski çekirdeğin büyük bir kısmı kullanıcı alanına taşınır ve sistem basitleştirilir.
Bu makalenin tartışmasına katılmak için, fikirlerinizi forumda paylaşmaktan memnuniyet duyarız:
Lütfen forum tartışmalarına nasıl katılacağınıza dair bilgi için Polkadot Forum Kullanım Kılavuzu'nu inceleyin.
波卡 tartışmalarına nasıl katılınır: Polkadot resmi forumu kullanım kılavuzu
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Teknik açıdan Polkadot'un JAM'ini açığa çıkarın
Yazan: Kian Paimani, Parity Core Developer
Derleme: Polkadot Labs
'Polkadot Bilgi Haritası', Polkadot'a giriş seviyesinde bir makaledir. Polkadot'un en temel kısımlarından başlayarak, Polkadot hakkında tam bir anlayış sağlamak için çalışıyoruz. Tabii ki bu büyük bir projedir ve dolu dolu zorluklarla doludur. Ancak, bu çabalarımızla Polkadot'un doğru bir şekilde tanınmasını ve Polkadot hakkında bilgisi olmayan insanların Polkadot ile ilgili bilgileri kolayca ve hızlı bir şekilde öğrenmelerini umuyoruz. Bugün bu bölümün 148. sayısıdır ve bu makale, Parity'nin ana geliştiricisi Kian Paimani tarafından Polkadot'un en yeni JAM protokolünü teknik açıdan açıklamak için yazılmıştır. Bu makale, yazarın birinci şahıs bakış açısıyla yazılmıştır.
*Polkadot1、Polkadot2 ve bunların JAM'a nasıl dönüştüğünün ayrıntılı açıklaması aşağıda verilmiştir. (Detaylar için bkz: ***) Bu makale, özellikle Polkadot'a çok aşina olmayan ancak blok zinciri sistemleri hakkında bazı bilgileri olan teknik personel ve diğer ekosistemle ilgili teknolojileri bilen okuyucular için hazırlanmıştır.
Benim düşünceme göre, JAM beyaz kağıdını okumadan önce bu metni okumak iyi bir başlangıçtır. (Detaylar için bkz:**)
Arka Plan Bilgisi
Bu metin, okuyucunun aşağıdaki kavramlara aşina olduğunu varsayar.
Önsöz: Polkadot1
Öncelikle, Polkadot1'in en yenilikçi özelliklerini düşünecek olursak.
Sosyal Düzey:
Teknik Açıdan:
「异构Parçalama」hakkında daha fazla bilgi için ilgili bölüme bakın.
Parça Yürütme: Önemli Çıkarımlar
Şu anda, Polkadot ve Ethereum gibi diğer Layer2 'blockchain' ağlarını barındıran bir Layer1 ağı tartışıyoruz. Bu nedenle, Layer2 ve Parachain terimleri birbirinin yerine kullanılabilir.
Blok zincirinin ölçeklenebilirliğinin temel sorunu şu şekilde formüle edilebilir: Proof of Stake'in (Proof-of-Stake) kripto ekonomisi aracılığıyla belirli kodların yürütülmesinin güvenilir olmasını sağlayabilecek bir grup doğrulayıcılar vardır. Varsayılan olarak, bu doğrulayıcıların birbirlerinin tüm işlerini yeniden gerçekleştirmeleri gerekir. Bu nedenle, tüm doğrulayıcıları her zaman her şeyi yeniden yürütmeye zorladığımız sürece, tüm sistem ölçeklenebilir değildir.
Lütfen dikkat edin, yukarıdaki mutlak yeniden yürütme prensibi değişmezse, bu modelde doğrulayıcılarının sayısını artırmak aslında sistemdeki verimliliği artırmayacaktır.
Yukarıda gösterilen, ParçalamaBlok zinciriyle karşılaştırıldığında bir tekil Blok zinciridir. Tüm ağ doğrulayıcıları girişi (yani Blok) sırayla işleyecektir.
Bu tür bir sistemde, Layer1 daha fazla Layer2 barındırmak istediğinde, doğrulayıcıların tümü şimdi tüm Layer2 işlerini yeniden yürütmek zorunda kalır. Açıkçası, bu yöntem ölçeklendirilemez. Optimistik Rolluplar, sadece biri dolandırma iddiasında bulunduğunda yeniden yürütülür (dolandırıcılık kanıtı). SNARK tabanlı Rolluplar, SNARK kanıtını doğrulamanın bunu oluşturmaktan çok daha düşük maliyetli olduğu gerçeği üzerinden bu sorunu atlatır, bu nedenle tüm doğrulayıcıların SNARK kanıtını doğrulamasına izin verir. Bu konuda daha fazla bilgi için "Ek: Ölçeklenebilirlik Uzay Haritası"na bakın.
Parçalamanın basit bir çözümü, doğrulayıcılar kümesini daha küçük alt kümeler halinde bölmek ve bu daha küçük alt kümeyle Layer2 Blok'ları yeniden yürütmelerine izin vermektir. Bu yöntemin sorunu nedir? Ağı ve ekonomik güvenliği parçalıyoruz. Layer2'nin güvenliği Layer1'in altında ve doğrulayıcılar kümesini daha fazla parçaladıkça güvenlik daha da düşecektir.
Optimistik Rollup'ların her zaman yeniden yürütme maliyeti olmadığına karşın, Polkadot Parçalama'yı tasarımında düşünerek bir kısmı doğrulayıcıların Layer2 Blokunu yeniden yürütmesine olanak tanır ve aynı zamanda tüm ağ katılımcılarına Layer2 Blokunun gerçekliğini ve doğrulayıcılar kümesinin onu yeniden yürüttüğünde olduğu kadar güvenli olduğunu kanıtlayan yeterli Crypto ekonomi kanıtı sağlar. Bu, yeni ve yenilikçi (yakın zamanda resmi olarak yayınlanan) ELVES mekanizmasıyla gerçekleştirilir. (Detaylar için bkz.:)
Kısacası, ELVES, bir tür 'şüpheci rollups' mekanizması olarak görülebilir. Birkaç tur doğrulayıcılar, belirli bir Layer2 Blok'un geçerliliğini diğer doğrulayıcılar aktif olarak sorgulayarak, bu Layer2 Blok'un geçerliliğini büyük olasılıkla doğrulayabiliriz. Aslında, herhangi bir anlaşmazlık durumunda, tüm doğrulayıcılar topluluğunun hızla katılmasını gerektirecektir. Polkadot'un kurucu ortağı Rob Habermeier, bu konuyu detaylı bir şekilde açıklayan bir makalede bu noktayı açıklamıştır. (Detaylar için bkz.: )
ELVES, Polkadot'un ölçeklenebilirlik açısından ana teknik başarısı olan, Polkadot'a önceki olarak karşılıklı dışlanan iki özelliği aynı anda sağlayan 'Parçalama Yürütme' ve 'Paylaşılan Güvenlik' özelliklerini kazandırır.
Şimdi, 'CORE' benzetmesini tartışmaya devam edelim.
Parçalama'yı yürüten bir blok zinciri, bir CPU'ya çok benzer: CPU'nun talimatları paralel olarak yürüten birden fazla çekirdeğe sahip olması gibi, Polkadot da Katman 2 bloklarını paralel olarak işleyebilir. Bu nedenle Polkadot üzerindeki Katman 2'ye parachain denir ve tek bir Katman 2 bloğunun doğrulayıcıların daha küçük bir alt kümesi tarafından yeniden yürütüldüğü ortama "çekirdek" denir. Her bir çekirdek "birlikte çalışan bir dizi doğrulayıcılar" olarak soyutlanabilir.
Tekil Blok zincirini, herhangi bir zaman diliminde yalnızca bir Blok'un alındığı şeklinde düşünebilirsiniz, ancak Polkadot, her zaman diliminde bir Rol zinciri Blok ve her bir çekirdek için bir paralel zincir Blok alır.
Heterojenlik
Şu ana kadar, sadece ölçeklenebilirlik ve Polkadot tarafından sağlanan Parçalama yürütmesini tartıştık. Dikkat edilmesi gereken nokta, Polkadot'un her Parçalama'nın aslında tamamen farklı bir uygulama olduğudur. Bu, bytcode içinde depolanmış bir meta protokol kullanılarak gerçekleştirilir: Blok zinciri tanımını Blok zinciri kendi durumunda bytcode olarak depolayan bir protokol. Polkadot 1.0'da WASM tercih edilen bytcode olarak kullanılırken, JAM'da PVM/RISC-V kullanılmıştır.
Sonuç olarak, işte Polkadot'un heterojen parçalı blokzinciri olarak adlandırılmasının nedeni budur. (Ayrıntılar için bkz: ) Her Layer2 tamamen farklı bir uygulamadır.
Polkadot2
Polkadot2'nin önemli bir parçası, çekirdeğin kullanımını daha esnek hale getirmektir. Orijinal Polkadot modelinde, çekirdek 6 aydan 2 yıla kadar herhangi bir süre için kiralanabilirdi, bu da iyi kaynaklara sahip işletmeler için uygundu, ancak küçük ekipler için o kadar iyi değildi. Polkadot Core'un daha esnek bir şekilde kullanılabilen özelliği "Agile CoreTime" olarak adlandırılıyor. Bu modda Polkadot Core, uzun süreli kiralamak isteyenler için tavan fiyat garantisi ile bir blok kadar kısa veya bir ay kadar uzun bir süre için kiralanabilir.
Polkadot 2'nin diğer özellikleri, tartıştığımız süreçte yavaş yavaş ortaya çıkıyor, bu nedenle burada fazla detaya gerek yok.
Core İç ve On-chain İşlemleri
JAM'ı anlamak için öncelikle bir Layer2 Blok'un Polkadot çekirdeğine nasıl girdiğini anlamak gerekmektedir.
Aşağıdaki içerik büyük ölçüde basitleştirilmiştir.
Gelin bir göz atalım, çekirdek aslında bir grup doğrulayıcılar tarafından oluşturulur. Bu nedenle, 'veriler çekirdeğe gönderildiğinde' ifadesi aslında bu verilerin bu grup doğrulayıcılara iletilmesi anlamına gelir.
Bir Layer2 Blok, Layer2'nin bir kısmıyla birlikte çekirdeğe gönderilir. Bu veriler, Layer2 Blok'un yürütülmesi için gereken tüm bilgileri içerir.
Bazı doğrulayıcılar Core içindeki Layer2 Blok'u yeniden çalıştırır ve Konsensüs ile ilişkili görevleri devam ettirir.
Core doğrulayıcılar, gerekli verileri diğer doğrulayıcılar (çekirdek dışı doğrulayıcılar) için yeniden yürütmeleri için sağlayacak. Diğer doğrulayıcılar, bu Layer2 Blok'un yeniden yürütülüp yürütülmeyeceğine ELVES kurallarına göre karar verebilir ve bu işlemi tamamlamak için bu verilere ihtiyaç duyarlar.
Dikkat edin, şu ana kadar tüm işlemler Polkadot'un ana blok ve durum geçiş fonksiyonları dışında gerçekleştirilmiştir. Her şey çekirdek içinde ve veri erişilebilirlik katmanında gerçekleşir.
Yukarıdaki içerikten, Polkadot'un gerçekleştirdiği bazı işlemleri tartışabiliriz:
Öncelikle, 1. adımdan çıkarıyoruz ki Polkadot'ta geleneksel blok zinciri durum dönüşüm fonksiyonundan farklı bir yeni yürütme yöntemi bulunmaktadır. Genellikle, ağdaki tüm doğrulayıcılar bir işlem gerçekleştirdiğinde ana blok zinciri durumu güncellenir. Bu durumu on-chain işlem olarak adlandırıyoruz, bu 3. adımda olur. Ancak, çekirdek içinde gerçekleşen durum (1. adım) bundan farklıdır. Bu yeni tür blok zinciri hesaplamasına çekirdek içi yürütme denir.
Sonra, 2. noktadan itibaren Polkadot'un yerleşik bir veri kullanılabilirliği (Data-Availability, kısaca DA) katmanı sağladığını ve Layer2'nin bunu otomatik olarak kullanarak performans kanıtlarının belirli bir süre boyunca kullanılabilir olduğunu çıkarabiliriz. Bununla birlikte, DA katmanına yayınlanabilen veri blokları sabittir ve her zaman Layer2 Blok'un yeniden yürütülmesi için gerekli olan kanıtları içerir. Dahası, parachain kodu hiçbir zaman DA katmanı verisini okumaz.
Yukarıdaki metni anlamak, JAM'ın temelini anlamak demektir. Özetle:
JAM
Önceki kısmın anlamını tam olarak anladığınızda, JAM'ın tanıtımına sorunsuz bir şekilde geçebiliriz.
JAM, Polkadot'tan ilham alan ve tamamen uyumlu olan yeni bir protokoldür. Amacı, Polkadot'ın relay chain'ini değiştirmek ve merkezi olmayan ve sınırsız bir şekilde temel kullanımı sağlamaktır.
JAM, Polkadot2 üzerine inşa edilmiştir ve Polkadot'un çekirdeğine erişimi daha da kolaylaştırmayı amaçlamaktadır, ancak agile-coretime'dan daha esnek ve sabit bir kısıtlama olmadan.
Bu, önceden tartışılan üç temel özgün kavramı geliştiricilere açığa çıkararak gerçekleştirilir: zincir üstünde yürütme, çekirdek içinde yürütme ve DA katmanı.
Başka bir deyişle, JAM'de geliştiriciler şunlara erişebilir:
Bu, JAM hedefinin temel bir açıklamasıdır. Fazla söze gerek yok, burada birçok basitleştirme yapıldı ve protokol hala evrilebilir.
Bu temel anlayışla, şimdi JAM'ın bazı ayrıntılarını daha da tartışabiliriz.
1 Hizmet ve İş Kalemleri
JAM bağlamında, eskiden Layer2/parachain olarak adlandırılan şey artık "Hizmet" olarak adlandırılıyor ve eskiden Blok/İşlem olarak adlandırılan şey artık "İş Öğesi" veya "İş Paketi" olarak adlandırılıyor. Özellikle, bir iş öğesi bir hizmete aittir ve bir iş paketi bir iş öğeleri koleksiyonudur. Bu terimler, Blok Chain/Layer 2'nin ötesinde çok çeşitli kullanım durumlarını kapsayacak kadar genel olacak şekilde kasıtlı olarak tasarlanmıştır.
Bir hizmet, fn refine() ve fn accumulate() olmak üzere üç giriş noktası ile tanımlanmıştır. İlk ikisi hizmetin çekirdek içinde yürütülen içeriği tanımlarken, ikincisi hizmetin on-chain'de yürütülen içeriğini tanımlar.
Son olarak, iki giriş noktasının adı da protokolün JAM (Join Accumulate Machine) olarak adlandırılmasının nedenidir. Join, yani fn refine(), Polkadot çekirdeklerinin farklı hizmetlerin yoğun çalışmasını eşzamanlı olarak işlediği bir aşama olan bu aşamaya denir. Veriler filtrelenir ve bir sonraki aşamaya geçer. Accumulate ise tüm yukarıdaki sonuçların ana JAM durumuna birikmesini ifade eder, yani on-chain yürütme bölümüdür.
İş öğeleri, bir çekirdek içinde, on-chain olarak hangi kodların yürütüleceği kesin olarak belirtilebilir ve içeriklerini nasıl / ne zaman / nereden okuyup yazacakları dağıtılmış veri gölünden (Distributed Data Lake) açıkça belirtilir.
2 Yarı Uyumlu
XCM hakkında mevcut bilgilere göz attığınızda (Polkadot'un seçtiği parachain iletişim dili), tüm iletişimin asenkron olduğunu göreceksiniz. Yani, mesaj gönderildikten sonra cevabını bekleyemezsiniz. (Detaylar için bkz: )
Asenkronlık, sistem tutarsızlığının bir göstergesi olup, sürekli Parçalama sistemleri (örneğin Polkadot 1 ve Polkadot 2 ve mevcut Ethereum Layer2 ekosistemi) için ana dezavantajdır.
Ancak, ancak Whitepaper'ın 2.4 bölümünde açıklandığı gibi, her zaman tüm kiracıları için tam olarak senkronize olan tamamen tutarlı bir sistem, yaygınlık, erişilebilirlik veya esneklikten ödün vermeden belirli bir düzeye kadar yükseliş gösterebilir. (Detaylar için bkz: )
Senkron ≈ Uygunluk || Asenkron ≈ Uyumsuzluk
Bu aynı zamanda JAM'ın öne çıktığı bir başka alandır: JAM, çeşitli özellikleri tanıtarak yeni bir ara durum olan yarı tutarlı bir sistem sağlar. Bu sistemde, sık iletişim kuran alt sistemler, genel sistemde tutarlılığı zorlamadan birbirleri arasında tutarlı bir ortam yaratabilir. Bu, beyaz kağıt yazarı Dr. Gavin Wood'un röportajında en iyi şekilde açıklanmıştır: (Ayrıntılar için bkz: _referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Başka bir anlayış şekli, Polkadot/JAM'ın bir Parçalama sistemi olarak görülmesidir, bu Parçalama'ların sınırlarının akıcı ve dinamik olarak belirlendiği anlamına gelir.
波卡一直是Parçalama的，并且完全异质化。
Şimdi, bu, Parçalama, heterojen olacak ve bu Parçalama'ların sınırları esnek bir şekilde belirlenebilecek, Gavin Wood'un Twitter'da dediği gibi "yarı tutarlı" sistem. (Detaylar için bkz: _src=twsrc%5Etfw、)
Bu mümkün kılan özellikler şunlardır:
2.JAM, herhangi bir belirli hizmet planlamasını zorunlu kılmaz. Sık iletişim gerektiren hizmetler, sıralayıcılarına ekonomik teşvik sağlayarak, bu sık iletişim gerektiren hizmetleri içeren iş paketleri oluşturabilir. Bu, bu hizmetlerin aynı çekirdek içinde çalışmasını sağlar ve birbirleriyle iletişim, bir senkronizasyon ortamında gerçekleştirilen gibi olur.
Dikkat edilmesi gereken nokta, yukarıdaki içerik JAM'de mümkün olsa da, protokol katmanında zorunlu olarak uygulanmamıştır. Bu nedenle, bazı arabirimlerin teorik olarak asenkron olduğu ancak sofistike bir soyutlama ve teşvik önlemleriyle pratikte senkron olarak görünebildiği beklenmektedir. Aşağıdaki bölümde tartışılacak olan CorePlay tam da böyle bir örnektir.
3 CorePlay
Bu bölüm, JAM ortamında bir deneysel fikir olarak tanımlanabilen ve yeni bir akıllı sözleşme programlama modeli olarak tanımlanabilen CorePlay'i tanıtır. Bu yazı yazılırken, CorePlay hala ayrıntılı olarak açıklanmamış bir fikirdir.
CorePlay'yi anlamak için öncelikle JAM'ın seçtiği Sanal Makine olan PVM'i tanıtmamız gerekiyor.
4 PVM
PVM, JAM ve CorePlay'in önemli bir ayrıntısıdır. PVM'nin düşük seviye ayrıntıları bu makalenin kapsamının ötesindedir, en iyisi alan uzmanlarının beyaz kitapta açıklamalarına bakmaktır. Bununla birlikte, bu makalenin ihtiyaçları doğrultusunda, sadece PVM'nin bazı özelliklerini açıklamamız yeterlidir:
Latter, CorePlay için özellikle önemlidir.
CorePlay, JAM kullanarak esnek bir dil oluşturmak için bir örnek oluşturuyor, senkronize ve ölçeklenebilir akıllı sözleşme ortamı, çok esnek bir programlama arayüzüne sahip. CorePlay, Actor tabanlı akıllı sözleşmelerin doğrudan JAM çekirdeğine dağıtılmasını önermektedir, böylece onlar senkronize programlama arayüzünden yararlanabilir, burada normal fn main() gibi yazılıp let_result=other_coreplay_actor(data).await? ile iletişim kurulabilir. Eğer other_coreplay_actor aynı JAM Blok içindeki çekirdekte ise, bu çağrı senkroniktir; eğer farklı bir çekirdekte ise, bu Actor durdurulur ve sonraki JAM Blok'ta devam eder. Bu durum, JAM servisleri ve esnek planlaması ile PVM özellikleri sayesinde mümkün hale gelir.
5 CoreChains Hizmet
Son olarak, JAM'ın Polkadot'a tamamen uyumlu olmasının ana nedenlerini özetleyelim. Polkadot'un ana ürünü, çevik temel zamanlı çalışan parachain'lerdir (Parachains), ve bu ürün JAM'da devam ettirilir.
JAM'da en erken dağıtılan hizmetlerden biri, CoreChains veya Parachains olarak adlandırılabilir. Bu hizmet, mevcut Polkadot -2 tarzı parachains'in JAM'da çalışmasına izin verecektir.
Daha fazla hizmet JAM'da dağıtılabilir ve mevcut CoreChains hizmetleriyle iletişim kurabilir, ancak Polkadot'un mevcut ürünleri güçlü kalacak ve yalnızca mevcut Parachain takımlarına yeni kapılar açacak.
Ek: Veri Parçalama
Bu makale, ölçeklenebilirlik açısından Parçalama yürütme perspektifinden çoğunlukla ele alınan içeriği tartışmaktadır. Aynı sorunu veri açısından da ele alabiliriz. İlginç olan, bu durumun yarı tutarlılık durumuyla benzerlik gösterdiğini bulmamızdır: İlkeler olarak, tamamen tutarlı bir sistem daha iyidir ancak ölçeklendirilemez; tamamen tutarsız bir sistem ölçeklendirilebilir ancak ideal değildir ve JAM, yarı tutarlılık modeliyle yeni bir olasılık sunar.
Tamamen Uyumlu Sistem: Bu, Solana gibi tamamen senkronize Akıllı Sözleşme platformunda veya yalnızca ETH Layer1'de dağıtılan cesur platformlarda gördüğümüz bir özelliktir. Tüm uygulama verileri on-chain'de depolanır ve tüm diğer uygulamalara kolayca erişilebilir. Bu, programlanabilir mükemmel bir özelliktir, ancak ölçeklenebilir değildir.
Tutarlı Olmayan Sistem：Uygulama verileri Layer1 dışında ve farklı, izole Parçalama'ların içinde saklanır. Son derece ölçeklenebilir, ancak kombinasyon açısından zayıf bir performans sergiler. Polkadot ve Ethereum'un Rollup modeli bu duruma örnektir.
JAM, yukarıda bahsedilen iki işlevi sağlamanın yanı sıra, geliştiricilere JAM DA katmanına herhangi bir veriyi yayınlama izni verir; bu, bir anlamda on-chain veri ve off-chain veri arasındaki orta noktadır. DA katmanını kullanan yeni türde uygulamaları yazabilir ve sadece mutlak önemli verileri JAM durumuna kalıcı olarak kaydedebilirsiniz.
Ek: Ölçeklenebilirlik Alanı Haritası
Bu bölüm, blok zinciri ölçeklenebilirlik alanındaki görüşümüzü yeniden açıkladı. Bu, beyaz kağıtta da açıklandığı gibi, burada daha özlü bir versiyon sunulmaktadır.
Blockchain'un ölçeklenebilirliği büyük ölçüde geleneksel dağıtık sistemlerde kullanılan yöntemleri izler: yukarı doğru ölçeklendirme (dikey) ve dışarı doğru ölçeklendirme (yatay).
Yukarı doğru genişleme, Solana gibi platformlar tarafından yapılan bir çalışmadır. Maksimum işlem hacmini elde etmek için kod ve donanımın sınırlarını optimize eder.
Dışa doğru genişleme, Ethereum ve Polkadot'un benimsediği bir stratejidir: herkesin yapması gereken iş miktarını azaltmak. Geleneksel dağıtık sistemlerde, bunun için daha fazla kopya makine eklenerek gerçekleştirilir. Blok zinciri içinde, 'bilgisayarlar', tüm ağın doğrulayıcılar topluluğudur. Onların arasında iş paylaşımı yaparak (ELVES'in yaptığı gibi) veya umut verici rollups'un sorumluluklarını azaltarak, doğrulayıcılar topluluğunun iş yükünü azaltarak sistem genişlemesini gerçekleştirdik.
Blok zincirinde, dışarı doğru genişleme, tüm işlemleri yürütme ihtiyacını azaltmak için gerekli makine sayısını azaltmaya benzer.
Aşağıda özetlenmiştir:
Ek: Aynı donanım, çekirdek güncellemesi
Bu bölüm, Rob Habermeier'in Sub02023'teki benzetmesine dayanarak: Polkadot: Çekirdek/Kullanıcı Alanı|Sub02023-YouTube (ayrıntılar için bkz.:), Polkadot'un yükseltmesi olarak JAM'ı gösteriyor: Aynı donanımda çekirdek güncellemeleri.
Tipik bir bilgisayarda, tüm yığını üç bölüme ayırabiliriz:
Donanım
Çekirdek
Kullanıcı Alanı
Polkadot'ta, donanım, hesaplama ve veri erişilebilirliği sağlayan temel bir özellik olmuştur, yukarıda belirtildiği gibi.
Polkadot'ta çekirdek aslında[9]Şu ana kadar iki bölüm içerir:
1.parachain (Parachains) protokol: bir görüşleme, çekirdek kullanımı için sabit bir yöntem.
Bu ikisi de Polkadot'un Orta Aktarma Zinciri (Relay Chain) üzerinde mevcuttur.
Kullanıcı alan uygulamaları, parachains'in örnekleridir, bunların yerli Token'ları ve üzerlerine inşa edilen diğer içerikleri.
Bu süreci aşağıdaki gibi görselleştirebiliriz:
Polka her zaman daha fazla temel işlevi parachain adlı benzersiz bir kullanıcıya taşımayı düşünmüştür. Bu, Minimal Röle RFC'nin gerçekleştirmeyi amaçladığı hedefdir. (Ayrıntılar için bkz: )
Bu, Polkadot ağının sadece parachainprotokol sağlayan paralel bir zincirle ilgilendiği anlamına gelir ve bu da çekirdek alanını kısmen daraltır.
Bu mimari bir kez gerçekleştirildiğinde, JAM göçünün nasıl görüneceğini daha kolay görselleştirmek mümkün olacaktır. JAM, Polkadot'un çekirdek alanını büyük ölçüde daraltacak ve daha genel kullanıma uygun hale getirecektir. Ayrıca, Parachains protokolü, aynı çekirdek (donanım) ve çekirdek (JAM) üzerinde uygulama yazmanın az sayıdaki yollarından biri olduğu için kullanıcı alanına taşınacaktır.
Bu aynı zamanda JAM'ın sadece Polkadot röle zincirinin yerine geçen bir şey olduğunu, parachain'in yerine geçmediğini açıkça gösteriyor.
Başka bir deyişle, JAM göçünü bir çekirdek yükseltme olarak düşünebiliriz. Temel donanım aynı kalırken, eski çekirdeğin büyük bir kısmı kullanıcı alanına taşınır ve sistem basitleştirilir.
Bu makalenin tartışmasına katılmak için, fikirlerinizi forumda paylaşmaktan memnuniyet duyarız:
Lütfen forum tartışmalarına nasıl katılacağınıza dair bilgi için Polkadot Forum Kullanım Kılavuzu'nu inceleyin.
波卡 tartışmalarına nasıl katılınır: Polkadot resmi forumu kullanım kılavuzu