
On-chain KYC ve beyaz liste ile izinli token'lar nasıl…
Zincir üstü KYC ve beyaz listelemenin nasıl çalıştığı, bir hareketle özetlenir: zincir dışı KYC/AML kararını zincir üstüne, makine tarafından kontrol edilebilir uygunluk haline dönüştürmek; bu, akıllı sözleşmelerin transfer veya erişim anında uygulayabileceği bir durumdur. Tasarım tercihi "KYC veya KYC yok" değil, kapının yığındaki yeri ve kuralların token içinde mi yoksa güncellenebilir uyum modüllerinde mi yaşadığıdır.
Anahtar Çıkarımlar
- KYC/AML kontrolleri genellikle düzenlenmiş sağlayıcılarla zincir dışı gerçekleşirken, zincir üstü katman, zincir üstü kimliğe bağlı olarak doğrulanabilir "uygun/uygun değil + nitelikler" sonucunu iddia olarak saklar.
- ERC-3643uyumu bir transfer ilkesine dönüştürür: token, bir Kimlik Kaydı ve bir Uyum Modülü kontrol eder ve eğer bu kontrollerden biri başarısız olursa işlem geri alınır.
- Beyaz listeleme, token sözleşmesinin ötesinde köprü, RPC ve konsensüs dahil olmak üzere birden fazla katmanda uygulanabilir; bu, kontrol ve açıklık arasında net bir takas sunar.
- Operasyonel kontrol düzlemi genellikle Kimlik Kaydı artı Uyum Modülü olup, bu sözleşmelerde güncelleme ve yönetici anahtar riski yoğunlaşır.
Zincir üstü KYC'nin kripto para içindeki yeri
İzin gerektirmeyen zincirler, herhangi biradresalmak ve göndermekvarlıklar, bu da düzenlenmiş ihraççıların birçok durumda izin veremeyeceği şeydirtokenleştirilmiş menkul kıymetlerve diğer kısıtlı enstrümanlar. Kısıtlama felsefi değil. Mekanik: bir varlık yalnızca uygun yatırımcılar tarafından tutulmalıysa, sistemin, bir transferin on-chain'de yerleşmeden önce durdurulması için bir yol bulması gerekir.
İşte burada “kod ile uyum” devreye giriyor. Zincir üzerindeki KYC ifadesi “kimlik belgelerini Ethereumüzerine koymak” olarak yanlış anlaşılıyor. Kaynaklardaki yaygın mimari tam tersidir. KYC ve AML kontrolleri hala düzenlenmiş sağlayıcılarla off-chain olarak gerçekleşirken, zincir, işlem zamanında uygunluğu makine ile kontrol edilebilir hale getirmek için gereken minimum bilgiyi tutar.
ONINO'nun tanımı açıktır: off-chain doğrulama sonucu, bir yatırımcının on-chain'de saklanan kriptografik talepler olarak temsil edilmektedir.ONCHAINIDve ardından transferler sırasında okunur.
Beyaz listeleme, bu talepleri tüketen uygulama kuralıdır. Bir token beyaz listesi, onaylı adreslerin bir haritası kadar basit olabilir, ancak modern tasarımlar “kimin izinli olduğu” sorusunu bir kimlik sorusu olarak, bir adres sorusu olarak değil, ele alır. Bu, izinli bir cüzdan modeli (bu adres izinli) ile kimliğe bağlı bir model (bu adres, uygun bir kimlikle bağlantılı) arasındaki farktır. Kimliğe bağlı yaklaşımda, bir adres dönebilirken uygunluk kimlik kaydına bağlı kalır.
Önemli olan diğer terim ise engellenmiş adres.Bu sistemlerde, engellenmiş bir adres sosyal bir etiket değildir. Uygunluk kontrollerini geçemeyen bir adres olup, bu nedenle ona yapılan transferler geri döner veya yığındaki başka bir kapıda erişimi reddedilir.
Beyaz listelemenin temel mekanizması
Tüm sistemi yönlendiren iki kaldıraç vardır ve çoğu açıklama bunları bir araya getirir.
Birinci kaldıraç kimlik ve uygunluk temsilidir. Kaynaklar, ONCHAINID'i ERC-3643 ile kullanılan zincir üstü kimlik katmanı olarak tanımlar ve güvenilir veya yetkilendirilmiş taraflar tarafından verilen talepler veya kimlik belgeleri ile birlikte gelir. AI CERTs, gizlilik modelini vurgular: hassas veriler zincir dışında kalırken, imzalar veya talepler zincir üzerinde tutulur. Bu ayrım, noktadır. Zincirin bir pasaport taramasına ihtiyacı yoktur. Bir verici tarafından imzalanmış “KYC geçildi” veya “yargı alanı = AB” gibi doğrulanabilir bir ifadeye ihtiyacı vardır.
İkinci kaldıraç kuralın uygulanmasıdır. Uygunluk zincir üzerinde temsil edildikten sonra, onu uygulayacak bir şey hâlâ gereklidir. Uygulama, bir token sözleşmesinin içinde, bir uygulamanın içinde veya yığının daha üstünde yer alabilir. Token seviyesinde, uygulama, her iki tarafın da uygun olması ve transferin kural mantığını karşılaması durumunda tokenın hareket etmeyi reddetmesi anlamına gelir. İşte buradabeyaz liste tokenifikir somut hale gelir: token kendisi kapı haline gelir.
Genel bir akış şöyle görünür:
1. Off-chain sağlayıcı bir kullanıcıyı doğrular ve hangi özelliklere sahip olduğuna karar verir (KYC geçti, akreditasyon, yargı yetkisi). 2. Güvenilir bir verici bu özellikleri, bir on-chain kimliğine bağlı olarak on-chain üzerinde iddialar olarak yazar. 3. Bir kayıt defteribağlantılarbir veya daha fazla cüzdan adresini o kimliğe ekler ve "bu adres şu anda uygun mu?" sorusuna yanıt verir. 4.
Bir token veya uygulama, bir işlem sırasında kayıt defterini ve herhangi bir kural motorunu kontrol eder. 5. Eğer bir kontrol başarısız olursa, işlem geri alınır, böylece durum değişmez ve transfer tamamlanmaz.
Çıktı “KYC on-chain” değil. Çıktı, transfer anında belirleyici bir evet/hayır ve sözleşmelerin uyguladığına dair bir denetim izi sunmaktadır.
ERC-3643'ün transferlerde KYC'yi nasıl zorladığı
ERC-3643, belgelerinde izinli token'ların ihraç edilmesi, yönetilmesi ve transfer edilmesi için açık kaynaklı bir akıllı sözleşmeler seti olarak konumlandırılmıştır. Ayrıca, yalnızca uygun kullanıcıların izinli blok zincirlerinde token sahibi olabilmesi için yerleşik bir merkeziyetsiz kimlik çerçevesi içermektedir.
ERC-20 ile net bir ayrım yapmaktadır: ERC-3643, transferlere izin vermeden önce kimlik ve uygunluğu kontrol eder, KYC ve AML gibi uyum gereksinimlerini destekler.
ONINO’nun ERC-3643/T-REX mimarisi sistemi dört bağlı bileşene ayırır: zincir üzerindeki kimlikler, bir kimlik kaydı, takılabilir uyum modülleri ve token sözleşmesi. Bu ayrıştırma önemlidir çünkü ekiplerin sistemin günlük olarak nerede çalıştığını gösterir.
ONINO tarafından tanımlanan transfer karar ağacı basit ve serttir, bu yüzden işe yarar:
1. Token sözleşmesinde bir transfer başlatılır. 2. Token, gönderici ve alıcı doğrulaması için Kimlik Kaydı'nı kontrol eder. 3. Token, kural ihlalleri için Uyum Modülü'nü kontrol eder. 4. Eğer herhangi bir kontrol başarısız olursa, işlem geri döner. Her ikisi de geçerse, transfer gerçekleştirilir.
Bu, ad-hoc beyaz listelere karşı anahtar pratik avantajdır. ERC 3643 üzerine inşa edilmiş bir izinli token, "elinden gelenin en iyisini" yapmaz ve daha sonra uzlaşmaz. Zincir, kurallar altında transferi kabul eder ya da etmez.
Uyum Modülü, kural uygulamasının modüler hale geldiği yerdir. ONINO, burada kodlanabilecek örnekleri listeler: yatırımcı limitleri, yargı yetkisi kısıtlamaları, kilitlenme süreleri ve sahip limitleri. ONINO ayrıca, uyum mantığının token sözleşmesinden ayrıldığı için token'ı yeniden dağıtmadan kuralların güncellenebileceğini belirtir. O ayrım, operasyonel kilidi açar ve aynı zamanda yönetişim ve güncelleme riskinin yoğunlaştığı yerdir.
Geleneksel piyasalarda, bir transfer ajanı, mülkiyetin resmi kaydını tutan ve belirli yaşam döngüsü olaylarını işleyen tarafa denir. ERC-3643 tarzı yığınlar, bu işlevin bazı kısımlarını sözleşmelere ve ajan rollerine kodlamaya yönelik bir girişimdir, böylece token kendisi kimin tutabileceğini ve transfer edebileceğini uygulayabilir.
KYC'nin uygulanabileceği diğer yerler
Conduit'in izinli DeFi kılavuzu, "nerede kapatacağınızı" bir yığın seçimi olarak çerçeveliyor, token-standart seçimi olarak değil. İzin vermenin uygulanabileceği dört altyapı katmanını tanımlar, bunlar zincirin açıklığı ve merkeziyetsizliği üzerindeki etkisine göre en azdan en çoğa sıralanmıştır: protokol, köprü, RPC ve konsensüs.
Protokol seviyesindeki kapatma en hedefli olandır. Conduit'in örneği, kimin bir token'ı tutabileceğini ve transfer edebileceğini uygulayabilen ERC-3643 gibi token standartlarına işaret eden varlık bazında beyaz listelemeyi göstermektedir. Bu, izinli bir token'ın, token'ın kendisi hareket etmeyi reddettiği için uygun olmayan sahiplerine ikincil transferleri engelleyebileceği yerdir.
Köprü seviyesindeki kapatma, çevre kontrolüdür. Conduit, köprü seviyesindeki KYC kapatmayı, bir ekosisteme kimin girebileceğini belirlemenin bir yolu olarak tanımlar. Bu, doğrulanmamış cüzdanların bir zincire varlık getirmesini engelleyebilir, ancak varlıklar kendileri de izinli değilse ekosistem içi transferleri otomatik olarak durdurmaz.
RPC seviyesindeki kapatma, varsayılan kullanıcı yolunu şekillendirir. Conduit, resmi RPC uç noktalarında coğrafi kısıtlamalar veya işlem onay iş akışları gibi örnekler verir. Bu kontroller politika olarak güncellenebilir ve birçok ağda kendi düğümlerini çalıştıran kullanıcılar tarafından atlanabilir. Bu, RPC kapatmayı uyum durumu için yararlı hale getirir, ancak sert bir garanti olarak daha zayıftır.
Konsens düzeyinde engelleme en güçlü ve en müdahaleci olanıdır. Conduit, bunun işlem dahil etme politikalarının sıralayıcı veya doğrulayıcı seti düzeyinde belirlenmesi olarak tanımlandığını belirtmektedir. Bu, her işlemin kurala tabi olduğu için en derin uygulamayı sağlar ve aynı zamanda açıklık üzerinde en büyük etkiye sahiptir.
Tasarımın sonucu basittir: token düzeyinde uygulama, belirli bir varlığın tutulmasını ve transferini kontrol etmekle ilgilidir, oysa köprü ve RPC kontrolleri giriş ve erişim yollarını kontrol etmekle ilgilidir.
Pratik ticaret dengeleri ve hata modları
İlk ticaret dengesi operasyonel kontrol ile güncelleme riski arasındadır. ONINO'nun modüler uyum çerçevesi, kuralların token'ı yeniden dağıtmadan değiştirilebilmesi nedeniyle cazip bir özelliktir. Maliyet, Uyum Modülü ve Kimlik Kaydı'nın kontrol düzlemi haline gelmesidir. Yönetici anahtarları, güncelleme izinleri ve denetim kapsamı burada kümelenir, token'ın ERC-20 benzeri yüzeyinde değil.
İkinci ticaret dengesi kullanıcı deneyimidir. Uygulama, kullanıcılara geri alınan işlemler olarak görünür, nazik bir uyarı olarak değil. Eğer bir alıcı uygun değilse, transfer başarısız olur ve gaz yine de harcanır. Açık ön kontroller ve okunabilir hata nedenleri sağlamayan sistemler, uyumu destek taleplerine dönüştürür.
Üçüncü ticaret dengesi “beyaz liste”nin gerçekten ne anlama geldiğidir. Statik bir adres listesi kırılgandır çünkü adresler döner, saklama düzenleri değişir ve kurumlar birden fazla cüzdan kullanır. Kimliğe bağlı modeller bu kırılganlığı azaltır, ancak kayıtlar ve güvenilir ihraççılara bağımlılık getirir.
Dördüncü ticaret dengesi merkeziyetsizlik duruşudur. Conduit'in katman sıralaması, yararlı bir zihinsel modeldir: protokol engellemesi dar ve bileşenlenebilirken, konsensüs engellemesi geniş ve zorlayıcıdır. Uygulamanın nerede olduğunu adlandırmadan “merkeziyetsiz uyum” iddiasında bulunan ekipler genellikle gerçek kontrol noktasını gizlemektedir.
Hata modları mimariyi takip eder. Eğer Kimlik Kaydı yanlışsa, uygun kullanıcılar engellenmiş bir adres gibi muamele görür. Eğer Uyum Modülü yanlış yapılandırılmışsa, yerleşmesi gereken transferler geri alınır. Eğer güncellemeler etrafındaki yönetişim dikkatsizse, kurallar karşı tarafların beklediğinden daha hızlı değişebilir. Bu nedenle, kodla uyum sadece yasal bir hikaye değildir. Bu, çok özel boğulma noktaları olan bir sistem tasarım hikayesidir.
Kaynaklar
Sıkça Sorulan Sorular
On-chain KYC, pasaportların veya kişisel verilerin on-chain'de saklandığı anlamına mı geliyor?
Hayır. Yaygın bir model, hassas verilerin off-chain'de kalmasıdır; zincir, uygunluğu temsil eden doğrulanabilir iddialar veya imzalar saklar. Bu iddialar, transferler veya erişim kontrolleri sırasında akıllı sözleşmeler tarafından kontrol edilebilir.
Token beyaz listesi ile kimlik tabanlı beyaz listeleme arasındaki fark nedir?
Basit bir token beyaz listesi genellikle onaylı cüzdan adreslerinin bir listesidir. Kimlik tabanlı tasarımlar, cüzdanları on-chain kimliğine bağlar ve uygunluğu bir kayıt ile kural mantığı aracılığıyla kontrol eder, böylece sistem statik bir adres listesi ile sınırlı değildir.
ERC-3643, uygun olmayan bir cüzdana transferleri nasıl engeller?
ERC-3643 tarzı tokenlar, gönderici ve alıcı doğrulaması için bir Kimlik Kaydı kontrol eder ve ardından kural ihlalleri için bir Uyum Modülü kontrol eder. Eğer bu kontrollerden biri başarısız olursa, işlem geri alınır, böylece transfer gerçekleştirilmez.
KYC ve beyaz listeleme, token sözleşmesi dışında nerelerde uygulanabilir?
İzin verme, protokol katmanında, köprü katmanında, RPC katmanında veya konsensüs katmanında uygulanabilir. Köprü ve RPC kontrolleri, giriş ve varsayılan erişim yollarını engelleyebilirken, konsensüs politikaları işlem dahil etme kurallarını ağ genelinde uygulayabilir.
Takımlar neden modüler uyum modüllerini kullanıyor, token'a kuralları sert kodlamak yerine?
Token sözleşmesini takılabilir uyum modüllerinden ayırmak, üst sınırlar, yargı kısıtlamaları, kilitlemeler ve sahip limitleri gibi kuralların token'ı yeniden dağıtmadan güncellenmesine olanak tanır. Dezavantajı, güncelleme ve yönetim kontrolünün uyum katmanında yoğunlaşmasıdır.