Güvenlik token'ları ve kripto piyasalarında uyum kodu

Güvenlik tokenleri, düzenlenmiş menkul kıymetlerin blockchain temsilleridir, bu nedenle sahiplikleri ve transferleri geleneksel araçlarla aynı yasal kısıtlamalara uymalıdır. “Kod ile uyum” tasarım deseni, bu kısıtlamaların bir token işlemi gerçekleştiğinde akıllı sözleşme kontrolleri, kimlik verileri ve idari kontroller kullanılarak deterministik olarak uygulandığı yerdir.

Ana Noktalar

• Bir güvenlik tokeni, bir güvenlik veya yatırım sözleşmesini temsil eder ve ABD Federal Menkul Kıymetler Yasaları altında geleneksel finansal araçlarla aynı kurallara tabidir.
• Kodla Uyumkripto sistemleri, madeni para basma, transfer etme, yakma veya onaylama anında izin verme veya reddetme kararlarını uygular ve genellikle belirsiz "KYC'd" etiketleri yerine standartlaştırılmış durum kodları döndürür.
• Token düzeyindeki kısıtlama standartları, dondurma ve iptal gibi programlanabilir kontroller ve yönetici kontrollerine odaklanırken, zincir veya hesap düzeyindeki izinler, kimin uzlaşmaya dokunabileceğini belirler.
• Etkileşimli öneriler, aynı düzenlenmiş kimlik ve veri nesneleri için uyumu taşınabilir hale getirmeyi teşvik ediyor.varlıkbirden fazla arayüz aracılığıyla ifşa edilebilir, kısıtlama şeffaflığını kaybetmeden.

Güvenlik tokenleri ve kodla uyumluluk

Düzenlenmiş varlıklar, hisse senedi tablosu bir 'akıllı sözleşme' olduğu için 'daha az düzenlenmiş' hale gelmez. Prometheum'un SEC'e sunulan mimari belgesi, blok zinciri menkul kıymetlerinin bir menkul kıymet veya yatırım sözleşmesini temsil ettiğini ve ABD'deki geleneksel finansal araçlarla aynı kurallara ve düzenlemelere tabi olduğunu açıkça belirtmektedir, bu da Federal Menkul Kıymetler Yasalarının hala geçerli olduğu anlamına gelir.

Bu çerçeve, güvenlik tokenlerinin açıklanması için başlangıç noktasıdır: token, düzenlenmiş bir yaşam döngüsünün etrafında bir sargıdır, bunun etrafında serbest bir geçiş değil.Kod ile uyum, en iyi şekilde bir mekan riski motoru gibi anlaşılır. Mülkiyet veya kontrolü değiştiren her eylem, makul bir neden ile birlikte bir izin veya reddetme kararı döndüren bir kapıdan geçirilir. Önemli tasarım tercihi, o kapının nerede bulunduğudur: token sözleşmesinin içinde, paylaşılan kimlik ve uyum veri nesnelerinin içinde veya yalnızca onaylı hesapların kabul edildiği izinli bir uzlaşma ortamının içinde.Bu nedenle 'güvenlik tokenleri vs. 'yaratım tokenleri' estetik bir meta veri tartışması değildir. Bir yaratım tokeni genellikle transferi varsayılan bir hak olarak değerlendirebilir. Bir güvenlik tokeni genellikle bunu yapamaz, çünkü uygunluk, yargı yetkisi ve yasal durum zamanla değişebilir. Bu nedenle, 'tokenizasyon' tartışmaları pazarlama katmanında kaldığında operasyonel noktayı kaçırır. Tokenizasyonun ne olduğunu arayan herkes genellikle yasal bir talebi programlanabilir duruma dönüştürmenin mekanikleriyle ilgilenmektedir. Güvenlik tokenleri, bu durumun bir düzenleyici altında savunulabilir ve bir transfer acentesi gibi aracılar için çalışabilir olması gereken durumdur.

Düzenlenmiş varlıklar, hisse senedi tablosu bir 'akıllı sözleşme' olduğu için 'daha az düzenlenmiş' hale gelmez.

Prometheum'un SEC'e sunulan mimari belgesi, blok zinciri menkul kıymetlerinin bir menkul kıymet veya yatırım sözleşmesini temsil ettiğini ve ABD'deki geleneksel finansal araçlarla aynı kurallara ve düzenlemelere tabi olduğunu açıkça belirtmektedir.Bu çerçeve, güvenlik tokenlerinin açıklanması için başlangıç noktasıdır.Kod ile uyum, en iyi şekilde bir mekan riski motoru gibi anlaşılır.Mülkiyet veya kontrolü değiştiren her eylem, makul bir neden ile birlikte bir izin veya reddetme kararı döndüren bir kapıdan geçirilir.Bir yaratım tokeni genellikle transferi varsayılan bir hak olarak değerlendirebilir.Bir güvenlik tokeni genellikle bunu yapamaz..

Zincir üstü transfer kısıtlamaları nasıl çalışır

ERC-1462, token herhangi bir geri alınamaz işlem yapmadan önce çalışan deterministik bir ön kontrol olarak uyumu ele alır. Önemli olan temel eylemler için açık kontrol işlevleri ekler: checkTransferAllowed, checkTransferFromAllowed, checkMintAllowed ve checkBurnAllowed. Token’ın ERC-20 yöntemlerinin, transfer, transferFrom ve onaylama işlevlerini geçersiz kılmak suretiyle bu kontrolleri danışması ve ardından sonucu uygulaması beklenir.

Önemli detay, ERC-1462'nin kararı bir boolean'a indirmemesidir. Kontrol işlevleri, 0x11'in İzin Verildi ve 0x10'un İzin Verilmedi anlamına geldiği standartlaştırılmış durum kodları döndürür, ayrıca ihraççıya özgü kodlar için alan bırakır. Bu, bir geliştirici inceliği gibi görünebilir, ta ki bir kullanıcı iş akışına ulaşana kadar.

Bir cüzdan, aracılık veya transfer ajansı sistemi, “KYC eksik olduğu için izin verilmedi” ile “yargı engeli nedeniyle izin verilmedi” veya “zincir dışı hata” arasında ayrım yapabilir; bu, destek talepleri ve manuel triage gerektiren genel bir geri dönüş yerine.

ERC-1462 ayrıca düzenlenmiş piyasalarda her zaman bulunan karmaşık kısımlara da yer açar: anlaşmazlıklar ve belgeler. EIP, KYC ve AML'yi gereklilikler olarak adlandırır ve bir hesabın token'larını kilitleme ve yasal bir anlaşmazlık nedeniyle transferleri kısıtlama yeteneğini açıkça içerir. Ayrıca, URI ve içerik hash'i ile zincir dışı yasal belgeleri referans alan isteğe bağlı belge kancalarını, attachDocument ve lookupDocument tanımlar. Bu, en dürüst haliyle uyum-kod duruşudur: zincir üstü uygulama artı zincir dışı yasal gerçekliğe kasıtlı bir köprü.

Token standartlarında yaygın uyum kontrolleri

ERC-1404, ihraççıların ve mekanların kamu raylarında düzenlenmiş akışlar yürütmeye çalışırken sürekli olarak talep ettikleri kontroller etrafında inşa edilmiş kısıtlı bir token standardıdır.

Site, token sahiplerini tanımanın ve yatırımcı adreslerinin beyaz listesini korumanın önemini vurgular; bu, bir beyaz liste token'ıve daha geniş bir fikrin bir parçası olanizinli token.Ayrıca, belirli yargı bölgeleri arasında transferleri engellemek ve maksimum mülkiyet sınırlarını uygulamak gibi, şartname ve danışmanlık notlarında yer alan karmaşık kısıtlamaları da vurgular.

Daha açıklayıcı kısım ise idari araç setidir. ERC-1404, bir token'ı dondurma, geri alma ve yeniden atama, birden fazla liste oluşturma ve bir işlemi onaylama veya reddetme gibi yaygın olarak uygulanan özellikleri listeler. Bunlar kenar durumlar değildir. Bunlar düzeltme araçlarıdır.

Eğer bir transfer daha sonra bir kısıtlamayı ihlal ettiği bulunursa veya biradresyaptırım altına alınırsa veya bir mahkeme kararı gelirse, bir üretim düzeyindeki güvenlik token'ının durdurma, geri alma veya durumu yeniden düzenleme yolu olmalıdır.

ERC-1404 ayrıca, Sahip veya İhraççı gibi rollerin ayrımını, bir transfer ajansı veya ticaret yeri olabilen bir Yönetici ve gönderip alabilen bir Yatırımcı rolü gibi örneklerle açıklar. Bu rol modeli, “kodla uyum”un bir slogan olmaktan çıkıp bir işletim sistemi haline geldiği yerdir. Dondurma, geri alma ve yeniden atama yetkisine sahip birinin olması gerekir ve token sözleşmesi bu izinlerin uygulanma noktası haline gelir.

Bu aynı zamanda güvenlik token standartlarının felsefede ayrıldığı yerdir. ERC-1462, ihraççıların kendi mantıklarıyla genişletebileceği dar bir taban için savunma yapar. ERC-1404, daha kapsamlı bir kısıtlı araç setine yönelir. Her ikisi de aynı ekran düzeyindeki sorunu çözmeye çalışıyor: bir kullanıcı gönder butonuna tıkladığında, token ya yerleşir ya da yerleşmez ve sistem nedenini açıklamalıdır.

Kimlik, saklama ve düzenlenmiş iş akışları

Bir token sözleşmesi transferleri engelleyebilir, ancak bir insanı kaydedemez. Bu nedenle, kodla uyum genellikle token etrafında bulunan kimlik, saklama ve mekan iş akışlarını kapsar. Prometheum’un mimarisi, izinli hesaplar modelini kullanan bir Core zincirinde düzenlenmiş faaliyetler ve Utility zincirinde açık model kullanılabilirliği ile bir ayrılmış Core ve Utility zincir modeli olarak temiz bir örnektir.

Kapama mekanizması ince değil. Prometheum, Core zinciriyle etkileşimde bulunan tarafların bir Broker-Dealer ile hesap oluşturabilmesi ve gerekli özen ile AML/KYC gerekliliklerini geçebilmesi gerektiğini belirtmektedir. Bu, bir sistem tasarım tercihi olarak zincir üzerinde KYC'dir, sadece bir onay kutusu değildir. Uygulamayı “sola” itiyor, böylece bir token transferi bile denemeden önce yerleşim ortamı kendisi izinli hale geliyor.

Prometheum ayrıca, bir blockchain dağıtılmış uygulamalarında token olarak da kullanılabilen, ABD'de kayıtlı bir güvenlik olarak Tanımlanan Akıllı Güvenlik Token'ını tanımlar ve bu token'ların “Master” ve “Personal” cüzdanlar arasında taşınması için mekanizmaları açıklar. Nokta, mülkiyet ve kayıt tutmadır.

Mimari, Core zincirinde muhasebe için temizleme firmaları tarafından kullanılan Master Cüzdanları ve Utility zincirinde kamu zinciri cüzdanları gibi davranan Personal Cüzdanları tanımlar. Transfer ajanı hizmetleri, broker-dealer'ların özel hesap sahibi verileriyle kamu blockchain verilerini birleştirerek mülkiyetin tam kaydını tutma işlevini yerine getirir.

Bu, ana karşılaştırmadır: token düzeyindeki kontroller, varlığı ortamlar arasında taşınabilir hale getirmeye çalışırken, izinli yerleşim ortamları, ortamın kendisini uyum perimetresi haline getirmeye çalışır. Her ikisi de izinli bir token deneyimi üretebilir. Sadece kapıyı farklı yerlerde koyarlar.

Etkileşim ve gelişen veri katmanları

Etkileşim çalışmaları, her ihraç edicinin her token sözleşmesi içinde aynı uyum yığınını yeniden icat etmesini önlemeye çalışıyor. EIP-7208 etkileşim ekinde, ERC-1400'ün güvenlik token'ları ihraç etme ve geri alma, mülkiyet ve transfer kısıtlamalarını yönetme ve token sahiplerine kısıtlamalar, haklar ve yükümlülükler açısından bakiyelerin alt kümelerinin nasıl davrandığı hakkında şeffaflık sağlama arayüzleri sunduğu açıklanmaktadır.

Bu “alt küme şeffaflığı” önemlidir çünkü düzenlenmiş token'lar genellikle bir tek bakiyenin ifade edemeyeceği dilimlere, kilitlenmelere veya kategoriye özel kısıtlamalara sahiptir.

Aynı ek, veri nesnelerinin güvenlik token'ları için uyum bilgisi veya mülkiyet detayları gibi zincir üzerindeki verileri depolayıp değiştirebileceğini ve güvenlik token standartları ile entegre edildiğinde özel kimlik yönetimi mantığının gömülebileceğini savunmaktadır.

Bu, mimari bir kaymadır: her kuralı bir token sözleşmesine sert kodlamak yerine, uyum durumu ve kimlik mantığı, birden fazla arayüzün okuyabileceği paylaşılan bir veri katmanında yaşayabilir.

İşte burada erc 3643 ve erc 1400 pratik entegrasyon hedefleri olarak ortaya çıkıyor. Ek, ERC-1400 altında ihraç edilen varlıkların bir vault veri nesnesine sarılması ve bunların veri yöneticisi arayüzleri aracılığıyla, ERC-3643 dahil olmak üzere, açığa çıkarılması gerektiğini açıkça belirtmektedir.

Ayrıca, depolama ayrımının, orijinal arayüzün bir parçası olmayan yeni işlevsellikleri mümkün kıldığı iddia edilmektedir; bunlar arasında rol tabanlı erişim kontrolü ve kimlik tabanlı kurtarma bulunmaktadır. Geliştiriciler için bu, “erc 3643 vs erc 1400 açıklaması” tartışmalarına köprü: bir mekanın istediği arayüz ile bir ihraç edicinin ihtiyaç duyduğu uyum durumu sonsuza dek birleştirilmek zorunda değildir.

Aynı yön, onaylı token yığınlarında kullanılan kimlik ilkelinde de ortaya çıkmaktadır, örneğin onchainid, burada kimlik ve talepler zincir üzerinde referans alınarak uygunluk mantığını desteklemek için kullanılabilir. Ortak hedef, kısıtlama netliğini kaybetmeden bileşenliktir, böylece cüzdanlar ve mekanlar bir transferin onaylanıp onaylanmayacağını tahmin edebilir.

Kodlanmış uyumun sınırları ve ticaretleri

İlk ticaret, belirlenebilirlik ile takdir arasındadır. ERC-1462, kontrol işlevleri içinde ihraç edici tanımlı mantığa izin verir ve hatta bir oracle aracılığıyla zincir dışı sorgulara izin verir. Bu, “kodla uyum”un hala zincir dışı kimlik doğrulama, yaptırım taraması ve yasal belirlemelere bağlı olabileceği anlamına gelir.

Kod, eylem anında kararı uygulayabilir, ancak politikanın ne olması gerektiğine karar veren bir yasal sürecin gerekliliğini ortadan kaldıramaz.

İkinci denge, taşınabilirlik ile çevre kontrolü arasındadır. ERC-1462 tarzı kontroller veya ERC-1404 tarzı kısıtlı transferler gibi token düzeyindeki kısıtlamalar, bir güvenlik tokenının cüzdanlar ve mekanlar arasında hareket etme olasılığını artırırken, kurallarını da yanında taşımasını maksimize eder.

Prometheum'un Core zincir modeli gibi zincir veya hesap düzeyindeki izinler, düzenlenmiş uzlaşmaya kimlerin katılabileceğini kontrol ederek kontrolü maksimize eder. Bu, geleneksel piyasa altyapısına daha yakın görünse de, çevre izinli olmadığı için açık bileşenliği azaltır.

Üçüncü denge, başarısızlık altındaki kullanıcı deneyimidir. Bir geri dönüş, kaba bir araçtır. ERC-1462'nin ERC-1066 aracılığıyla durum kodu yaklaşımı, kullanıcıların doğru şeyi düzeltmesini sağlamak için hataları anlaşılır hale getirmeye yönelik doğrudan bir girişimdir; bu, eksik KYC, bir yargı engeli veya bir dış hata olabilir.

Sadece bir beyaz liste token kontrolü uygulayan sistemler, neden kodları olmadan destek ve manuel istisna yönetimi maliyetini artırma eğilimindedir.

Son olarak, kodlanmış uyum, yönetilmesi gereken idari güç yaratır. ERC-1404'ün dondurma, iptal etme ve yeniden atama, çoklu liste izinleri ve onaylama veya reddetme kontrolleri, düzenlenmiş düzeltmeler için tasarlanmıştır. Ayrıca, ihraç eden veya yöneticinin bakiyelere müdahale edebileceği anlamına gelir.

Bu, düzenlenmiş piyasalarda bir hata değildir, ancak açıklamalarda ve entegrasyonların varlığı nasıl ele aldığı konusunda açık olması gereken bir tasarım kısıtlamasıdır.

Alıntı

Bir güvenlik tokenını "ERC-20 artı KYC" olarak sunan takımları izledim ve ardından ilk çirkin operasyonel günde: tartışmalı bir transfer, bir yargı değişikliği veya bir mekanın genel bir geri dönüş yerine temiz bir neden kodu istemesiyle şaşırdılar. ERC-1462'nin açık kontrol fonksiyonları ve ERC-1066 durum kodları üzerindeki ısrarı, bu yığın içindeki mekan dereceli risk motoruna en yakın şeydir. Sistem bir transferin neden engellendiğini açıklayamıyorsa, düzenlenmiş akış için hazır değildir.

En temiz zihinsel model, kapı konumunu erken seçmek ve sonuçlarını sahiplenmektir. Token düzeyindeki kontroller varlığı taşınabilir tutar. Prometheum'un Core zinciri gibi zincir veya hesap düzeyindeki izinler çevreyi sıkı tutar. Pahalı hata, kimlik ve kısıtlamalar için net bir gerçeklik kaynağı olmadan ikisini karıştırmak ve ardından her cüzdan ve entegrasyonun "izin verilen" ifadesinin farklı bir versiyonunu gördüğünü keşfetmektir.

Kaynaklar

• Ethereum İyileştirme Teklifleri
• ERC-1404
• ABD Menkul Kıymetler ve Borsa Komisyonu
• Ethereum İyileştirme Önerileri