Varlık yöneticileri XRPL Batch için hazırlanıyor. Gerçekte ne yapabilir?

Temel vaat basit: ilgili adımların tek bir defter kapanışında sonuçlanmasını sağlamak. Bir token teslim edip ödeme alması gereken bir varlık yöneticisi, varlığı önce gönderip paranın gelmesini ummak yerine ya hep ya hiç şeklinde bir takası tercih edebilir. RippleX, daha önceki kurumsal ilgi raporunda ele alındığı üzere, varlık yöneticilerinin ve ticari projelerin bu özelliğe hazırlandığını belirtti. Bu açıklamada, ana ağda canlı bir Batch işlemi gerçekleştiren üretimdeki bir varlık yöneticisinin adı kamuya açıklanmadı.

Durum, orijinal eylül sonu beklentisinden önce değişti. XRPL Foundation sürüm duyurusu, 3.4.1 sürümünü güvenlik açısından hassas konular için acil bir güncelleme olarak nitelendiriyor. Duyuru, fixBatchV1_2'yi ekliyor, sunucuların derhal yükseltme yapmasını istiyor ve süper çoğunluk desteğinin sürmesi halinde değişikliğin 9 Ekim'de etkinleştirilmesinin beklendiğini belirtiyor. Bu, kesin bir lansman vaadi değil, koşullu bir beklentidir.

Batch, eylemleri tek bir defter kapanışı içinde koordine eder

XLS-0056 spesifikasyonu, iki ila sekiz iç işlem barındıran bir dış işlemi tanımlar. İlgili hesaplar koleksiyonu onaylar. Seçilen bir mod, bir iç eylem başarısız olduğunda ne olacağını kontrol eder. Defter, koleksiyonu tek bir kapanışta işler ve ilgisiz gönderimler arasındaki, bir katılımcıyı anlaşmanın yarısıyla bırakabilecek boşluğu önler.

Bir fonun tokenleştirilmiş bir tahvil alacağını transfer ettiğini ve bir dolar tokeni aldığını varsayalım. İki sıradan işlem ayrı ayrı gönderilebilir. İlki başarılı olur ve ikincisi başarısız olursa, karşı taraflar operasyonel bir anlaşmazlık ve potansiyel kayıpla karşı karşıya kalır. Ya hep ya hiç modunda, amaçlanan takasın tamamlanması için her iki iç eylemin de başarılı olması gerekir. Token, ödeme aracı, karşı taraflar ve izinlerin halihazırda mevcut olduğu varsayıldığında, bu zorlayıcı kurumsal kullanım senaryosudur.

Batch bir tahvil oluşturmaz, zincir dışı sahipliğini doğrulamaz veya bir bankayı ödeme tokenini itfa etmeye zorlamaz. Defter eylemlerini koordine eder. Yasal mutabakat kesinliği, transfer kısıtlamaları, saklama ve itfa hâlâ ilgili enstrümanlara ve kurumlara bağlıdır. Bu ayrım önemlidir çünkü teknik olarak atomik bir transfer, teslim karşılığı ödemenin yalnızca bir parçasıdır.

Tek hesaplı eğitim, daha basit durumu gösterir. Tek bir hesaptan gelen birden fazla eylem, belirli bir modda paketlenebilir. Çok hesaplı işlemler, bakiyeleri veya izinleri etkilenen hesaplardan imzalar ekler. Çok hesaplı eğitim, bu koordineli imzalama sürecini açıklar.

Dört mod, dört farklı anlaşma üretir

ALLORNOTHING temiz iki taraflı takastır. Gerekli her iç eylem başarılı olmalıdır veya amaçlanan grup sonuçlanmaz. ONLYONE alternatifleri dener ve farklı toleranslardaki emirler gibi ilk başarıdan sonra durur. UNTILFAILURE bir diziyi bir başarısızlığa kadar işler. INDEPENDENT, aynı sarmalayıcıdaki eylemlerin bağımsız olarak başarılı veya başarısız olmasına izin verir. Dört modun tümünü günlük anlamda atomik olarak adlandırmak, kısmi tamamlanma olasılığını gizler.

Modlar ürün tasarımını değiştirir. İki varlığı tek bir ödemeye karşı hareket ettiren bir fonun, tek bir başarısız transferin tüm paketi iptal edip etmeyeceğine karar vermesi gerekir. Yedek teklifler gönderen bir piyasa yapıcı ONLYONE'ı tercih edebilir. Birden fazla ödeme dağıtan bir ihraççı bağımsız sonuçları tolere edebilir, ancak o zaman operasyon ekibi hangi alıcılara ödeme yapıldığını mutabakat etmek zorundadır. Mod bir biçimlendirme seçimi değil, bir risk kararıdır.

Sekiz eylem sınırı bir başka gerçek sınırdır. 1.000 yatırımcı transferini sonuçlandırmaya çalışan bir yönetici, mevcut teklif kapsamında 1.000'in tamamını tek bir Batch'e saramaz. Teorik minimum olan 125 sekiz eylemli pakette, bu gruplar kendi aralarında atomik olmaz. Ücretler, imzalar, hesap sırası yönetimi ve hizmet kapasitesi, zincir dışı iş süreci dikkate alınmadan önce bile pratik kısıtlamalar haline gelir.

Önceki teknik rapor, yükseltmenin uzun geliştirme ve denetim geçmişine dikkat çekmişti. Bu arka plan zamanlama açısından önemlidir, ancak üzerine inşa edilen her uygulamanın denetlendiği iddiasıyla karıştırılmamalıdır.

Dış başarı kodu bir muhasebe tuzağıdır

Spesifikasyon, iç işlemler başarısız olsa bile bir dış Batch işleminin tesSUCCESS raporlayabileceğini söylüyor. Dış sonucu, sıra ve ücret işlemeyi kapsar. Bir ödemenin veya teslimatın gerçekleşip gerçekleşmediğini bilmek için yazılımın iç işlem meta verilerini ve bireysel sonuç kodlarını incelemesi gerekir. Bu, arka ofisi genel bir başarı durumunu kayıtlı bir varlık hareketine dönüştüren herhangi bir kurum için alışılmadık derecede somut bir entegrasyon tehlikesidir.

Yalnızca dış sonucu okuyan ve bir müşteriye tokenleştirilmiş bir menkul kıymet kredisi veren bir ticaret akışı hayal edin. İlgili iç transfer başarılı olmadıysa, akış ve defter birbirinden ayrılır. Sistemin her iç eylemi üst öğesiyle ve kendi sonucuyla ilişkilendirmesi gerekir. Spesifikasyon, kaşiflerde ve dizinleyicilerde ParentBatchID ilişkisinin kullanılmasını önerir. Bir masa, yalnızca mutlu yolu değil, her moddaki başarısızlıkları test etmelidir.

Hata, dış işlem gerçek olduğu ve bir işlem kimliğine sahip olduğu için sıradan kontrollerden kurtulabilir. Bir işlemin bir iş eylemine eşit olduğu varsayımıyla kurulmuş bir mutabakat sistemi ilk kontrolünden geçebilir. Doğru kontrol, iş talimatını moda, eksiksiz imzalı pakete, her iç sonuca ve nihai varlık bakiyelerine bağlar. Bu, ağ katmanı doğru olsa bile bir varlık yöneticisinin yapması gereken bir iştir.

Aritmetik mütevazı ama aydınlatıcıdır. Sekiz iç işlem içeren maksimum bir Batch tek bir dış gönderimdir, ancak dış ücret ve sıralama kontrolüne ek olarak en az sekiz sonuç kontrolü gerektirebilir. 1.000 iç eylemi temsil eden 125 tam paket için arka ofisin 125 yeşil durum ışığına değil, 1.000 eylem düzeyinde sonuca ihtiyacı vardır.

Güvenlik düzeltmesi etkinleştirme hikayesini değiştiriyor

Vakfın 25 Eylül duyurusu, fixBatchV1_2'nin yanlış sarmalayıcıya sahip iç işlemleri reddettiğini ve ek güvenlik ve kararlılık düzeltmeleri içerdiğini söylüyor. Değişikliğin güvenlik açısından hassas doğası nedeniyle kaynak kodunu geçici olarak gizliyor ve daha sonra yayınlama ve geriye dönük bir inceleme sözü veriyor. Bu, dışarıdakilerin ifşadan önce tam yamayı inceleme yeteneğini sınırlar. Bu, açıklanmamış istismar edilebilirlik hakkında spekülasyon yapmak için değil, kesin atıf için bir nedendir.

Duyuru, düzeltme etkinleştiğinde yükseltme yapmamışlarsa 3.4.1 altındaki sunucuların değişiklik engelli hale geleceğini söylüyor. Doğrulayıcı oyları ve düğüm yükseltmeleri bu nedenle üretim erişimi için önemlidir. Bir yeter sayının destek sinyali vermesi, her cüzdanın, saklayıcının, API sağlayıcısının ve muhasebe aracının Batch için hazır olmasıyla aynı şey değildir. Önceki XRPL düğüm yükseltme kapsamı, önceki bir sürümdeki bir değişiklik engelinin operasyonel etkisini göstermektedir.

Ayrıca bir muhabirin atlayamayacağı bir geçmiş var. Şubat ayındaki bir güvenlik açığı ifşası, fonlanmamış bir imzacı ilk sırada göründüğünde diğer imzacılar için yetkilendirme kontrollerini atlayabilecek daha önceki bir Batch tasarımındaki bir kusuru açıklıyor. Değişiklik canlıya alınmamıştı. Güvenlik denetimi hesabı, bağımsız incelemenin üretim kullanımından önce sorunları nasıl yakaladığını inceledi. Eylül yaması ayrı olarak açıklanan bir sarmalayıcı sorunuyla ilgilidir; her iki olay da mevcut tasarımın güvensiz olduğunu kanıtlamaz, ancak her ikisi de dağıtım zamanlamasının neden incelemeyi hak ettiğini açıklar.

Kurumlar ne kazanabilir ve hâlâ neye ihtiyaç duyarlar

Ödemeye karşı atomik teslimat en güçlü durumdur. Bir yönetici, sıralı transferlerin yarattığı geçici riski sınırlayarak aynı defterde bir token transferini ödemeyle koordine edebilir. Bir ihraççı, protokolün bu işlem türlerine izin verdiği yerlerde hesap kurulumu, yetkilendirme ve ihraç adımlarını paketleyebilir. Ticaret firmaları alternatif yürütme yollarını kullanabilir. Bunlar yeteneklerdir, canlı varlıkların ve işlemlerin kanıtı değildir.

Tokenleştirilmiş varlıklar ihraççılar, transfer acenteleri veya diğer sorumlu kuruluşlar, uygun sahiplerle ilgili kurallar, saklama prosedürleri ve kabul edilebilir itfa koşullarına sahip bir ödeme aracı gerektirir. Bir Batch, zincir üstü adımların seçilen bir kural altında yürütülmesini sağlayabilir. Bir menkul kıymeti başka bir yargı bölgesinde yasal olarak geçerli kılamaz, ilgisiz bir eylem için müşteri onayı alamaz veya ticari bir bankadaki harici bir nakit ayağını garanti edemez.

Ripple'ın durumu en güçlü versiyonunu hak ediyor. Defter düzeyinde bir mekanizma, geliştiriciler için koordinasyon işini azaltabilir ve gerçek bir kısmi mutabakat başarısızlığı sınıfını ortadan kaldırabilir. XRPL özellik genel bakışı, Batch'i diğer kurumsal işlevlerle birlikte tanımladı, ancak her değişiklik kendi sürecini izler. Adı geçen yöneticiler daha sonra doğru şekilde mutabakat edilmiş iç sonuçlarla gerçek tokenleştirilmiş varlıkların canlı, tekrarlanan mutabakatını gösterirse, benimseme iddiasının arkasında somut kanıt olacaktır.

Sınır da aynı derecede açıktır. Bir pilot hazırlayan bir şirket, Batch'i üretimde kullanan bir varlık yöneticisi değildir. Hiçbir kamuya açık hazırlık iddiası bize hacimleri, tasarruf edilen ücretleri, önlenen mutabakat anlaşmazlıklarını veya hangi kurumun zincir dışı yükümlülükleri üstlendiğini söylemez. Bir duyuru doğru olabilir ve yine de bu daha büyük sonuçları desteklemek için çok erken olabilir.

Defterin oyu yalnızca ilk hazırlık testidir

fixBatchV1_2'nin beklenen 9 Ekim etkinleştirmesi, sürekli doğrulayıcı desteğine bağlıdır. Operatörlerin uyumlu yazılım çalıştırması gerekir. Cüzdanlar, spesifikasyonun önerdiği gibi, bir imza toplamadan önce kullanıcılara tüm iç eylemleri ve seçilen modu göstermelidir. Dizinleyiciler üst ve alt sonuçları göstermelidir. Saklayıcılar çok hesaplı imzalar için politika kontrollerine ihtiyaç duyar. Varlık yöneticilerinin mutabakat ve yasal belgelere ihtiyacı vardır.

Tüm bu hazırlığı gösteren tek bir yüzde yoktur. Doğrulayıcı oylaması, bir protokol değişikliğine yönelik anlaşmayı ölçer. Üretim testi, gerçek kullanıcıların uyumsuz kayıtlar olmadan başarısız bir Batch'i hazırlayıp hazırlayamayacağı, imzalayıp imzalayamayacağı, gönderip gönderemeyeceği, inceleyip inceleyemeyeceği ve kurtarıp kurtaramayacağıdır. Yanıtlanmamış ticari soru, değişiklik ve araçlar canlıya alındığında hangi adı geçen kurumun tekrarlanabilir bir kullanım senaryosu göstereceğidir.