Teknik Bilgiler Polkadot'un Yeni İlerlemesi: Varlık Merkezi, Rezerv Çok Zincirli Varlıkları Destekliyor

Joe Petrowski, Web3 Foundation System Parachain Takım Lideri tarafından yazıldı.

OneBlock Topluluğu tarafından derlenmiştir

İnsanların büyük çoğunluğu varlıkları "Tether" veya "USDT" gibi isim veya sembollerle tanımlamaya alışkındır. Ethereum'a aşinaysanız, 0x sözleşme adreslerine alışkınsınızdır.

Polkadot'ta Asset Hub, varlık kimlikleri olarak basit tamsayıları kullanarak varlık işlevselliğini doğrudan protokolde barındırır. "1984" adı biraz arsız, ancak insanların hatırlaması (ve doğrulaması) kesinlikle 0xdAC17F958D2ee523a2206206994597C13D831ec7 daha kolay.

Polkadot artık bu varlık işlevinin başka bir paralel örneğine sahiptir, ancak bu örnek, varlığı tanımlamak için çoklu konum adı verilen bir XCM ilkel kullanır. Bu açıklama aracılığıyla, bu özelliğin Polkadot ağı içinde ve içinde varlık kullanımı için etkileyici ve güçlü bir model oluşturduğunu iletmeyi umuyorum.

! [Teknik Detaylı Polkadot Yeni İlerlemesi: Varlık Merkezi Rezerv Çok Zincirli Varlıkları Destekliyor] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-310f5be259-dd1a6f-69ad2a.webp)

"Çok konumlu" tanınabilirYerel ve harici varlıklar

Asset Center ilk kullanıma sunulduğunda, Varlıklar paletinin yalnızca bir örneğini barındırıyordu ve herkesin kullanılabilir bir varlık kimliği talep etmesine ve varlıklarını oluşturmasına olanak tanıyordu. Asset Center, her varlık için özel bir sözleşmeye sahip olmak yerine, varlık mantığını birinci düzey temel öğe olarak ekler. Her varlık aynı işlevselliğe sahiptir.

Bu talep edilebilir, tamsayı tabanlı öğe kimliği tabanlı varlıklar yerel varlıklar olarak adlandırılır. Varlık merkezleri öncelikle bu varlıkların yaratıcıları tarafından, genellikle USDT gibi rezerv destekli sabit paralar tarafından kullanılır. Bununla birlikte, protokol yalnızca varlık kimliklerinin, bu durumda tamsayıların benzersizliğini zorlar. İçerik oluşturucular, varlık sembolleri gibi meta verileri ayarlayabilir. Bu nedenle, kullanıcıların yine de varlık üzerinde biraz durum tespiti yapması gerekir; Herkes varlığına USDT adını verebilir, ancak kullanıcılar genellikle Tether tarafından oluşturulan USDT'yi seçmek ister.

Varlık Merkezi, varlık yaratıcıları için bir "yönetim portalı" görevi görerek token basmalarına ve yakmalarına ve ağdaki diğer konumlara gönderilen tokenler de dahil olmak üzere Polkadot ağındaki toplam ihracı bilmelerine olanak tanır.

Ancak varlık kimliklerinin kendileri çok anlamlı değildir. Doğrulanması sözleşme adresinden daha kolay olsa da, kimlik kullanıcıya varlık hakkında herhangi bir bilgi iletmez. XCM'nin (Çapraz Konsensüs Mesaj Formatı) sırası buradadır.

Çoklu konum, göreli yolları ifade eder. "Süpermarkete nasıl giderim" açıklamasına göre konumları, başlangıç konumuna bağlı olarak farklı yönlere sahip olacaktır. En temel düzeyde, bu yollar diğer zincirlerin yönünü temsil eder ve aynı zamanda hemen hemen her şeyin yönünü ifade edebilir: varlıklar, sözleşmeler, panel endeksleri, yönetişim organları, hesaplar vb.

Çok konumlu, genellikle iki bölüme ayrılmış bir dizi kesişme noktasına sahiptir: "ebeveynler" ve "ebeveynler: 1, iç: Parachain(9.000)" gibi genişletilmiş yollar. Bu, "ebeveynime git ve oradan 9.000 parachain'e" anlamına gelir. Burada "ebeveyn" fikir birliği içeren bir sistemdir. Örneğin, bir röle zinciri, parachain'leri içeren bir konsensüs sistemidir, parachain ise akıllı sözleşmeleri içeren bir konsensüs sistemi olabilir. Bu örnekte, varlık merkezi gibi başka bir parachain'den birden fazla konum gelebilir. Parachain 9.000, aynı ebeveyni, röle zincirini paylaştıkları için bir çift kardeş olacak.

Öğe tanımlayıcıları olarak, birden fazla konumun mutlak tanımlayıcılara (ör. adres, karma, tamsayı) göre önemli avantajları vardır. İlk olarak, bir varlığın birden fazla konumu, kontrol eden kuruluşun göstergesidir. Yukarıdaki örnekte Parachain 9.000'in yönetişimi yer almaktadır. Mutlak tanımlayıcıları görüntülerken, kullanıcılar veren kuruluşa ve zincir içi tokenler ve zincir dışı varlıklar gibi taleplerine bire bir güvenmelidir. Çoklu pozisyon, aslında varlıkları kontrol etme mantığını gösteren parachain'leri, akıllı sözleşmeleri veya diğer protokolleri içerir. Ancak bu, kullanıcıların gerekli tüm durum tespitinden vazgeçebilecekleri anlamına gelmez, örneğin parachain 9.000'in güvenilir bir "süper kullanıcıya" sahip olması gibi. Ancak çoklu konum, varlığın hangi protokol tarafından kontrol edildiğini kullanıcıya iletebilir.

Birden fazla pozisyonun son noktasının ötesinde, aslında "emir komuta zincirini" açıklığa kavuşturur. Daha uzun bir örnek için, kimliği 42 olan parachain 9.000 varlık: "ebeveynler: 1, iç: Parachain(9.000), PalletIndex(99), GeneralIndex(42)". Bu varlık, parachain'in konsensüsünün içinde yer alan bir palet tarafından kontrol edilir ve bu da paylaşılan ana şirketin (röle zinciri) konsensüsü içinde bulunur. Çoklu konum, "ebeveynler: 2, iç: GlobalConsensus (Ethereum)" gibi tamamen harici bir konsensüs sistemini bile temsil edebilir. Parachain perspektifinden bakıldığında bu, "iki seviye yukarı (yani röle zincirinin üstüne) ve ardından Ethereum'un konsensüsüne geçmek" anlamına gelir.

Bu konumlar Unix dosya yollarına çok benzer, örneğin ": /Parachain (9000)/PalletIndex (99)/GeneralIndex (42)" veya ".. /.. /GlobalConsensus (Ethereum)"。

Sonuç olarak, Polkadot'un varlık merkezi, Polkadot'tan erişilebilen herhangi bir varlığı temsil edebilir. Yerel bir panel veya sözleşme, XCMP veya köprü, protokol yerel belirteci veya zincirin diğer yerel varlıkları aracılığıyla çağrılmış olsun, Varlık Merkezi tüm varlıklar için ortak bir arabirim sağlar ve varlığın tanımlayıcısı bağımsız konumunu iletir.

İki tür varlık transferi ilişkisi: **Transfer ve rezerv

XCM dilinin konum/çift varlık transferi ilişkisini ifade etmenin iki yolu vardır: ışınlanmalar ve rezervler. Bunlar, varlık merkezi ile diğer zincirler arasındaki ilişkiyi ve bunların nasıl etkileşime girdiğini tanımlar.

**İletim basittir. İki zincir belirli bir varlık için birbirine güvendiğinde, gönderici onu basitçe yok edebilir ve alıcıdan onu basması için bir talimat verebilir. Gönderici, alıcının gönderilen numaradan daha fazlasını basmayacağına güvendiği sürece, gönderici aynı iletim talimatını kabul edebilir.

**Rezervler daha karmaşıktır. Varlığın kaynaklandığı zincir başka bir zincire güvenmediğinde, varlığı hedef zincirin egemen hesabına koyabilir ve hedef zincire varlığın yerel hesabına kaydedildiğini belirten bir mesaj gönderebilir. Hedef zincir daha sonra kullanıcıları için türev varlıkları basabilir. Rezerv tamamlandıktan sonra, hedef zincir, kaynak zincire varlığı hesabından çıkarması talimatını veren bir yanıt mesajı gönderebilir (ilgili türev varlığı yok ettiğini varsayarak).

Rezervler söz konusu olduğunda, güven ilişkisi tek yönlüdür. Basılmış türev varlıklar zinciri, ihraç eden zincirin egemen hesap bakiyesini koruyacağına ve itfalara saygı duyacağına güvenir. Bununla birlikte, ihraç eden zincir, varlıkları doğru bir şekilde ele almak için hedef zincire güvenmez.

Burada dikkat edilmesi gereken bir nokta, konum/varlık çiftlerinde güven ilişkilerinin var olduğudur: yani, bir zincir belirli varlıkları teslim etmek için başka bir zincire güvenebilir, ancak diğer şeyleri transfer edemez.

Peki, kim kime güveniyor? Neye güvenmeli? Varlıklar her zaman çok konumlu paradigmada "üstlerine" güvenirler. Örneğin, Parachain 8.000'de bulunan bir akıllı sözleşme, Parachain 8.000'in yönetimine güvenirken, Parachain 8.000, Polkadot Relay Chain'e güvenir. Polkadot röle zincirleri "kök köken" tarafından yönetilir ve parachain'leri atmak da dahil olmak üzere herhangi bir talimatı yerine getirebilir. Polkadot'un Root Origin'i aynı zamanda tüm sistem parachain'lerini de yönetir (aslında, röle zinciri ve tüm sistem parachain'leri tek bir "Polkadot protokolü" olarak düşünülebilir).

Polkadot ağındaki akıllı sözleşmeler gibi tüm zincirler ve alt protokoller Polkadot'a güvenir, bu nedenle protokol ile varlıkları transfer edebilmelidirler. Aslında, rezervleri kullanmak aptalca olurdu: Polkadot, orijin zincirindeki rezerv bakiyesini beğenmezse, bir kök orijin referandumu yoluyla en sevdiği bakiyeyi doğrudan yeniden yazabilir.

Öte yandan, Polkadot bu evrensel güveni içindeki üyelere genişletemez. Ancak, o konumdan kaynaklanan varlıkları yönetmek için bir konuma güvenebilir. Protokol, yerel tokenini (PNT, "pint"?) yönetmek için Parachain 9.000'e güvenebilir. ) ve yerel olarak verilen tokenler gibi içinde oluşturulan varlıklar. Bu nedenle, Parachain 9.000 ile etkileşime girerken, Varlık Merkezi, PNT'nin bu parachain'den kaynaklandığını kabul etmek için bir PNT iletecektir. Parachain 9.000 için, varlık merkezi PET rezerv transferini kullanacaktır (Parachain 8.000 token, daha az belirsiz).

**Varlık Merkezi rezerv pozisyonu olarak hizmet eder, **İnteraktif sınırsız varlıklar

PET'in oluşturulması, Polkadot protokolünün yönetişimini kabul eden Parachain 8.000'in yönetişimi tarafından kontrol edilir. Bu nedenle Polkadot, Parachain 8.000 protokolünün bir parçası olan Parachain 8.000'in PET'ine doğal olarak güvendi. Ancak ne Polkadot ne de Parachain 8.000, PET için yedek pozisyon olarak hareket etmek için diğer parachain'lere güvenmiyor.

(* Not: Bununla birlikte, güven de bir seçenektir: Parachain 8.000, tıpkı birçok sistem zincirinin Polkadot OpenGov kökenlerini tanıması gibi, yönetişim kökenleriyle özdeşleşen başka kardeşlerine sahip olabilir. Bu bağlamda, ayrı zincirler yerine birden fazla zincir içerebilen egemen bir sistemi düşünmek daha iyidir. ）

Bu kavram, emir komuta zinciri boyunca Parachain 8.000 içinde oluşturulan diğer varlıklara kadar uzanır. Uygulamada, bunun bağımsız zincirler veya eşzamansızlık ile ilgisi yoktur; Aynı zincirdeki iki akıllı sözleşme, birbirlerinin varlıklarını yönetmek için birbirlerine güvenmeyebilir, ancak her ikisi de içinde bulundukları zincire güvenir.

Bu iki yönlü güven ilişkisi göz önüne alındığında, Varlık Merkezi rezerv varlıklar için bir varış noktası görevi görebilir. Parachain 8.000, PET'ini varlık merkezine aktarabilir ve bu da daha sonra diğer konumlar arasındaki transferler için bir rezerv konumu görevi görebilir. Bu, Parachain 9.000'in varlık merkezini PET'inin diğer parachain'lere göndermesi için bir rezerv konumu olarak kullanabileceği anlamına gelir.

Ancak, bu diğer konumlar artık hem Parachain 8.000'i hem de Varlık Merkezi'ni PET için yedek konumlar olarak kabul edebilir.

Uygulamada, varlık merkezlerini bu şekilde kullanmak isteyen protokoller (parachain'ler, akıllı sözleşmeler vb.), belirli bir varlık için birden fazla rezerv lokasyonunu yönetme fikrini gerektirecektir. Pratikte bu, her varlık için bir rezerv konumu seçmek anlamına gelebilir ve parachain'ler ile diğer protokoller arasındaki ortak protokoller ve standartlar da etkileşimlerini basitleştirecektir.

Polkadot ağında binlerce protokol vardır ve tüm protokollerle iletişim kanalları kurmak zahmetli, istenmeyen veya pratik değildir. Bir protokol her protokolle bir iletişim kanalı kurmak istemediği için, yine de varlıklara ücretsiz erişim isteyebilir. Varlık Merkezi, yalnızca Polkadot ağındaki varlıkları değil, Polkadot ağından erişilebilen herhangi bir varlık için bir rezerv konumunu temsil edebildiğinden ve bu konum olarak hareket edebildiğinden, varlık merkezi, bir protokolün neredeyse sınırsız sayıda varlığı yönetebileceği ve bunlarla etkileşime girebileceği tek bir rezerv konumu olarak hareket edebilir.

Kod Uygulaması: Parachain varlıklarını Varlık Merkezi'ne aktarın**

Parachain varlıklarını varlık merkezine teslim eden bir XCM programının nasıl yazılacağına dair bir örneğe bakalım. Bu mantığı parachain'lere eklemek isteyen geliştiriciler için dikkat edilmesi gereken iki nokta var.

İlk olarak, bir XCM programının yürütülmesi, programın kaynağı değil, program örneğinin yürütülmesi açısındandır. Bu, uygulamanın varlık hub'ı perspektifinden varlıklara ve konumlara başvuran programlar göndermesi gerektiği anlamına gelir.

İkincisi, ücreti ödemek kolay olmayabilir. DOTS'u sistem zincirleri arasında aktarırken veya DOT'ları egemen hesaplarda tutan zincirler için rezerv talimatlarını kullanırken, bu uygulamalar işlem yaptıkları varlıkları kullanarak ücret ödeyebilir. Ancak Varlık Merkezi, ücret ödemek için uygulamanızın varlıklarını kabul etmeyebilir, bu nedenle uygulamanızın ücretleri kabul edilebilir varlıklarla ödemesi gerekir. Varlık Dönüştürme eklemek, süreci daha basit ve daha esnek hale getirecek, ancak zincirin yine de ücret ödeyebilecek işlem çiftleri başlatması gerekecek.

Sürecimize birkaç varlık tanımlayarak başlayın: DOT ve parachain 9.000 yerel varlık PINT'leri ve alıcı varlığın lehtarı:

! [Teknik Detaylı Polkadot Yeni İlerlemesi: Varlık Merkezi Rezerv Çok Zincirli Varlıkları Destekliyor] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6f1578732f-dd1a6f-69ad2a.webp)

Varlık merkezine gönderilen bir program oluşturmadan önce, gönderenin aktardığı varlıkların bir hesabını tutması gerekir. Daha zarif kullanım için XCM aktüatörleri ile bir zincir de yapılandırılabilir.

! [Teknik Detaylı Polkadot Yeni İlerlemesi: Varlık Merkezi Rezerv Çok Zincirli Varlıkları Destekliyor] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-706b50806e-dd1a6f-69ad2a.webp)

Şimdi, Varlık Merkezi'ne gönderdiğiniz XCM programını oluşturmaya başlayın:

! [Teknik Detaylı Polkadot Yeni İlerlemesi: Varlık Merkezi Rezerv Çok Zincirli Varlıkları Destekliyor] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4a86958556-dd1a6f-69ad2a.webp)

Bu program, prosedürü gerçekleştirmek için gereken ağırlıkları satın almak, gönderilen PINT'leri almak, kullanılmayan ağırlıkları iade etmek ve son olarak iki varlığı (DOT artı PINT'lerdeki tüm değişiklikleri çıkararak) lehtar hesabına yatırmak için parachain bağımsız hesabından DOT'u çekecektir.

Gönderenin bu iletiyi göndermeden önce bazı muhasebe işlemleri yapması gerekebileceğini unutmayın. Bu tür bir program oluşturma doğrudan kullanıcıya sağlanmamalı, ancak harici programların uygun şekilde incelenmesinden sonra sağlanmalıdır. Gönderenin DOT'un güvenilir bir vericisi olmadığı neredeyse kesindir, bunun yerine gönderen her iki varlığı da iletebilir ve para çekme için egemen hesabında DOT olmayabilir.

Bu, yerel zincirlerinde hisse senedi destekli bir türev DOT'a sahip olabilecekleri anlamına gelir. Bu DOT'u devlet hesabından çekin ve ücret ödemesine aktarın, yararlanıcı rezervlerini azaltacaktır. Bu nedenle, gönderen bu mesajı göndermeden önce bu rezerv desteğinin açıklamasını imha etmelidir, böylece zincirlerinin rezervde tam teminatı olmaz. Gönderen, aktarımı başlatan kullanıcıdan kesinti yapabilir veya çıkarma için kendi DOT kitaplığını tutabilir (ve bazen rezervi yenileyebilir). Daha eksiksiz bir örnek için, Trappist'te yapılan muhasebe bölümüne bakın:

🔗

Sonuç

Varlık merkezine harici varlıklar eklemek, varlık tanımlayıcıları olarak birden çok konum ve birden çok rezerv konumu gibi yeni paradigmalar açarak ağ içinde anlamlı ve rahat etkileşim sağlar.

Parite, dış varlıklarla çalışmaya yönelik bazı yaygın kalıpları göstermek için önümüzdeki aylarda daha fazla örnek ve eğitim yayınlayacak. Parachain geliştiricileri Rococo'da Trappist'e dikkat etmeli, cüzdan/entegrasyon geliştiricileri ise varlık transferi API'lerine dikkat etmelidir:

🔗