JAM, 2.0'dan sonra, merkezi olmayan bir JAM istemcisi (JAM gri kağıt protokolüne dayalı) uygulamak için 30'dan fazla ekip, farklı programlama dilleri ve farklı geliştirme ekipleriyle araştırma ve geliştirmeyi hızlandırıyor. En eski ETH, tüm doğrulayıcıların birlikte doğrulamasını gerektiren tüm işlemlerdi (bu kısım aslında Ethereum Sarı Kitabında okunabilir ve daha iyi bir yorumlama versiyonu vardır). L2, zincirin daha küçük bir alt kümesinin hesaplamaları gerçekleştirmesine izin vermektir, iki şekilde, bir L2 sahtekarlık kanıtıdır (doğrulamak için sahtekarlık bulduktan sonra işlem kodunu tekrar tekrar yürütün) ve diğer L2, çift hesaplama gerektirmeyen bir zk kanıtıdır, ancak kanıt oluşturmak için zk'nin daha pahalı GPU'sunu kullanması gerekir. Daha önceki @Polkadot 1.0, ETH'nin pasif doğrulama kullanan dolandırıcılık algoritmasına benzemeyen, ancak aktif doğrulama için olasılıksal bir algoritma türü kullanan ELVES adlı bir algoritma kullanıyordu. @polkadot 2.0 doğrulama seti, Core adı verilen bir konsept halinde paketlenmiştir, core esasen doğrulama setinin bir alt kümesidir, 2.0 Agile Coretime'ı yani core'un dinamik kullanımını destekler, 1.0 zincir başına sadece bir core kullanabilir, 2.0 canlıya geçmek üzere ve Agile Coretime'ı destekler, yani bir zincir ihtiyaca göre dinamik olarak coretime (doğrulama alt kümelerinin sayısı) kullanabilir, böylece sistemin servis yükünü artırır. JAM, yukarıdaki fikirlere dayanmaktadır ve bu kadar çok zk, OP, akıllı sözleşme ve hatta sıradan web2 durumsuz uygulamayla, bu farklı uygulama modellerine uyum sağlamak ve birbirleriyle etkileşime girmelerine izin vermek için hizmetleri soyutlamaya bir adım daha yaklaşabilir mi? Böylece JAM bu temelde soyutlamaya bir adım daha yaklaştı. - Çeşitli farklı L2/parachain şeyleri artık hizmet olarak adlandırılıyor - Blok/işlem öğeleri artık iş öğesi veya iş paketi olarak adlandırılıyor - Bir iş öğesi bir hizmettir, bir iş paketi ise bir iş öğeleri kümesidir - Hizmet, ikisi fn refine() ve fn birikmiş olmak üzere üç giriş noktası ile tanımlanır. - Bu iki giriş noktasının isimleri tam olarak protokolün neden JAM: Join Accu Machine olarak adlandırıldığıdır. Birleştirme, tüm Polkadot çekirdeklerinin farklı hizmetler için paralel olarak çok fazla iş gerçekleştirdiği fn refine() anlamına gelir. Birleştirme, verilerin daha küçük bir alt kümeye damıtılması ve ardından bir sonraki aşamaya geçirilmesi anlamına gelir. - Birikim, yukarıdaki işlemlerin tümünün sonuçlarının ana JAM durumuna biriktirilmesi anlamına gelir - Farklı hizmet biçimleri desteklenir (OP toplamaları, zkrollup'lar, parachain'ler, durum bilgisi olmayan uygulamalar, akıllı sözleşmeler) ETH dönemi, paylaşılan duruma sahip tek sütunlu bir durum makinesidir, @polkadot 1.0 dönemi, birlikte çalışabilir olasılık parçalarıdır. @polkadot 2.0 çağı, Agile Coretime makinesidir. JAM dönemi, Join Accu Machine'dir (JAM) Çok detaylı özellik var, burada sadece bilgi senkronizasyonundan anladığım şey şu, neden daha derinlemesine anlıyorum, JAM işlemler yoluyla programları çağırmaya gerek kalmadan sürekli çalışan programlar elde edebiliyor, gelecekte bu tür bir özellik DEFI ile birleştirildiğinde hangi yeni model ürünler üretilecek? JAM neden JAM DOOM gibi durum bilgisi olmayan uygulamaları çalıştırabilir? Ayrıntılar için videoya bakın: Çalışma materyalleri: