Kripto para göndermenin en temel kullanıcı deneyimi sorunlarından biri, insanların uzun ve hata yapmaya açık blockchain adresleriyle uğraşmak zorunda kalmasıdır. Bir banka transferinde telefon numarası veya kolay tanınabilir hesap bilgisi kullanılabilirken, kripto para sistemlerinde kullanıcı çoğu zaman doğru blockchain ağını seçmek, karmaşık bir adresi kopyalamak ve işlem ücretini ödemek için ilgili ağın yerel tokenına sahip olmak zorundadır.

Bunu çözmenin en basit yolu bir e-posta adresini doğrudan blockchain adresine bağlamak gibi görünebilir. Fakat bu yaklaşım ciddi bir gizlilik sorunu doğurur. Bir kişinin e-posta adresinden deterministik olarak blockchain adresi üretilebiliyorsa, e-posta adresini bilen herhangi biri o kişinin bakiye, işlem geçmişi ve karşı taraf ilişkilerini halka açık zincir üzerinden inceleyebilir.

HFIPay, bu problemi insan tarafından kolay kullanılan tanımlayıcı ile blockchain üzerindeki ödeme adresini doğrudan birbirine bağlamayarak çözmeyi amaçlayan bir protokol mimarisidir. Sistem; özel tanımlayıcı yönlendirmesi, gönderici tarafından doğrulanabilir teklif, intent'e özel körlenmiş bağlama ve sıfır bilgi ispatıyla zincir üzerinde claim authorization katmanlarını birbirinden ayırmaktadır.

Gönderici yalnız alıcının e-posta adresi gibi bir tanımlayıcıyı belirtir. Bir relay bu tanımlayıcıyı özel veritabanında çözümler, her ödeme için rastgele bir intentId üretir ve zincire alıcının e-posta adresini veya tekrar kullanılabilen kalıcı bir alıcı etiketi yerine yalnız o işleme özgü blinded binding değeri olan ρ'yı kaydeder.

Verified-quote modunda gönderici, para göndermeden önce ρ değerinin gerçekten hedeflenen alıcının gizli bağlama anahtarına ait olduğunu bir off-chain proof ile doğrulayabilir. Para yatırıldıktan sonra ise relay parayı istediği başka bir alıcıya yönlendiremez; gerçek alıcı, ZK-ACE üzerinden aynı deterministik kimlik ailesine sahip olduğunu sıfır bilgi ispatıyla kanıtlayarak fonları seçtiği adrese aktarabilir.

Çalışma ayrıca HFIPay'in n-Vm mimarisiyle birleştirildiğinde farklı blockchain ortamları arasında ödeme yönlendirmesi için kullanılabileceğini tartışmaktadır. Ancak mimari henüz uçtan uca performans benchmark'larıyla doğrulanmamıştır.

İnsan dostu kripto ödeme adresi neden gizlilik problemi yaratıyor?

Bir kullanıcının:

alice@example.com

adresinin doğrudan:

keccak256(identifier) → blockchain address

gibi deterministik bir yöntemle blockchain adresine dönüştürüldüğünü düşünelim.

Kullanım açısından son derece kolay görünen bu sistem, blockchain'in şeffaflığı nedeniyle ters etki oluşturur. Alice'in e-posta adresini bilen herhangi bir kişi aynı işlemi yaparak Alice'in blockchain adresini hesaplayabilir.

Bundan sonra saldırgan halka açık zincirde:

• hesap bakiyelerini,
• geçmiş transferleri,
• hangi tokenların tutulduğunu,
• hangi adreslerle işlem yapıldığını,
• işlem zamanlarını

inceleyebilir.

HFIPay'in temel tasarım kararı bu nedenle “insan dostu tanımlayıcı = halka açık blockchain adresi” eşitliğini tamamen kaldırmaktır.

HFIPay E-posta Adresini Blockchain'de Açıklamadan Ödemeyi Nasıl Yönlendiriyor?

HFIPay'de e-posta adresi, telefon numarası veya sosyal medya kullanıcı adı blockchain üzerinde doğrudan yer almaz. Tanımlayıcı özel relay katmanında çözülür ve blockchain tarafında her ödeme için yeni oluşturulan tek kullanımlık bilgiler kullanılır.

Protokolde beş temel rol vardır:

Alıcının gizli bağlama anahtarı

Alıcı B, deterministik kimlik kökü REVB üzerinden belirli bir binding epoch için özel bir handle üretmektedir:

u_B,e = H(Derive(REV_B, Ctx_bind || e))

Bundan halka açık teklif doğrulamasında kullanılabilecek binding-key commitment oluşturulur:

K_B,e = H("hfipay:bind-key" || u_B,e)

Burada e binding epoch değeridir. Makale, epoch etiketinin alıcıya özgü rastgele bir kimlik olmak yerine günlük veya haftalık gibi kaba ve ortak bir zaman çizelgesinden seçilmesini önermektedir. Amaç, epoch bilgisinin kendi başına yeniden kullanılabilir bir alıcı etiketi haline gelmesini engellemektir.

Her ödeme neden yeni bir intentId kullanıyor?

Gönderici ödeme istediğinde relay kriptografik olarak rastgele bir 256-bit intent kimliği üretmektedir:

intentId ← {0,1}²⁵⁶

Daha sonra zincire gönderilecek tek kullanımlık blinded recipient binding hesaplanır:

ρ = H("hfipay:bind" || u_B,e || intentId)

Aynı alıcıya yeniden para gönderildiğinde yeni bir intentId üretildiği için ρ da değişir.

Bu özellik HFIPay'in pre-claim unlinkability hedefinin merkezindedir. Blockchain gözlemcisi iki farklı intent'in aynı e-posta adresine ait olduğunu gösterecek sabit bir recipient tag görmez.

Baseline ve Verified-Quote neden iki ayrı güven modeli?

Baseline modunda relay kötü niyetli davranırsa ödeme öncesinde başka bir alıcıya ait blinded binding oluşturabilir. Kaynak bunu açıkça güven varsayımı olarak bırakmaktadır.

Verified-quote modunda ise bağımsız binding layer, normalleştirilmiş kullanıcı tanımlayıcısı ile alıcının binding-key commitment değeri arasındaki bağlantıyı tasdik eder.

Relay daha sonra göndericiye bir quote proof sağlar. Bu proof aynı gizli uB,e değerinin hem:

K_B,e = H("hfipay:bind-key" || u_B,e)

hem de:

ρ = H("hfipay:bind" || u_B,e || intentId)

ilişkilerini sağladığını kanıtlar.

Gönderici parayı transfer etmeden önce proof'u ve zincire kaydedilmiş intent tuple'ını doğruladığı için relay'in sonradan alıcıyı değiştirmesi engellenmeye çalışılır.

Gönderici Parayı Gönderdikten Sonra Relay Parayı Başka Bir Adrese Çevirebilir mi?

Verified-quote modelinin temel güvenlik amacı bunun önüne geçmektir.

Gönderici fonlamadan önce:

1. binding attestation'ı doğrular,
2. quote proof'u doğrular,
3. deposit adresini intentId üzerinden kendisi yeniden hesaplar,
4. asset, miktar, chain, expiration ve refund alanlarını kontrol eder,
5. blockchain üzerinde kayıtlı intent tuple'ının kabul ettiği quote ile aynı olduğunu doğrular.

Zincirde örneğin:

(ρ, a, v, e, Texp, γA, href)

bilgileri intent'e bağlandıktan sonra relay'in alıcı, token, miktar veya refund semantiğini sessiz biçimde değiştirebilmesi için göndericinin doğrulamasını veya kullanılan kriptografik yapıları aşması gerekir.

Ödeme süreci beş ana fazdan oluşuyor

EVM üzerinde ödeme adresi nasıl oluşturuluyor?

EVM uyumlu blockchain'lerde HFIPay, deterministik deposit adresini CREATE2 üzerinden tanımlamaktadır:

α_EVM = CREATE2(factory, intentId, keccak256(initcode))

Bunun önemli özelliği adresin contract henüz gerçekten deploy edilmeden önce hesaplanabilmesidir.

Factory contract aynı zamanda intent'e ait ρ, asset, miktar, epoch, expiration ve refund bilgilerini saklayabilir.

Solana üzerinde nasıl uygulanıyor?

Solana tarafında karşılık gelen yapı Program Derived Address kullanmaktadır:

α_SOL = FindPDA(programId, ["hfipay" || intentId])

Intent state PDA içinde:

• ρ,
• asset descriptor,
• miktar,
• epoch,
• expiration,
• refund metadata

saklanmaktadır.

SPL token kullanıldığında program ayrıca intent'e ait PDA-controlled token vault oluşturabilir.

Claim sırasında alıcı neyi kanıtlıyor?

Alıcı zincire doğrudan “Ben şu e-posta adresiyim” dememektedir.

Bunun yerine ZK-ACE kullanarak deterministik kimliğinin intent üzerindeki blinded binding ile uyumlu olduğunu sıfır bilgi ispatıyla kanıtlamaktadır.

Claim mesajı kaynakta şu yapıyla tanımlanmaktadır:

m_i = H("hfipay:claim" || d_dep || c_i || a_i || e_i || intentId_i || ρ_i || v_i || β_i || Texp || n_i)

Buradaki β, alıcının fonları almak istediği destination address; n ise replay saldırılarına karşı nonce'dur.

Claim proof şu ilişkileri birlikte bağlar:

deterministik kimlik → epoch handle → ρ → intentId → asset → miktar → destination

Bu nedenle bir mempool gözlemcisi claim transaction'ını kopyalayıp önce göndermeye çalışsa bile proof fonun saldırgan tarafından seçilmiş başka bir destination address'e aktarılmasını yetkilendirmez.

Intent yaşam döngüsü

Her intentId yalnız bir kez kullanılmaktadır.

CREATED → FUNDED → CLAIMED

veya:

FUNDED → EXPIRED → REFUNDED

yollarından biri izlenmektedir.

Refund işlemi de relay'in tek taraflı kararına bırakılmamıştır. Kaynağın modelinde gönderici, intent oluşturulurken refund destination için önceden authorization sağlayabilir.

HFIPay Hangi Gizlilik Özelliklerini Hedefliyor?

1. Enumeration Resistance

Bir saldırgan Alice'in e-posta adresini biliyor olsa bile, yalnız blockchain verisini inceleyerek hangi intent'lerin Alice'e ait olduğunu belirleyememelidir.

Zincirde görünen temel bilgiler şunlardır:

Kaynak, gizlilik iddiasının asset türü, miktar, zamanlama veya chain bilgisini gizlediğini söylememektedir. Enumeration resistance analizi bu açık metadata eşitlenerek yapılmaktadır.

2. Pre-Claim Unlinkability

Aynı kullanıcıya claim gerçekleşmeden önce iki farklı ödeme yapıldığında, dış gözlemci bu iki intent'in aynı kişiye ait olduğunu yalnız on-chain yapıdan anlayamamalıdır.

Bunun temel nedeni her intent'in bağımsız rastgele intentId kullanması ve blinded binding'in:

ρ_i = H("hfipay:bind" || u_B,e || intentId_i)

biçiminde her seferinde yeniden oluşmasıdır.

Claim gerçekleştikten sonra anonimlik aynı mı kalıyor?

Hayır. Makale bu sınırı açık biçimde kabul etmektedir.

Alıcı tekrar tekrar aynı public destination address β'yı kullanırsa bu claim'ler ortak kontrol altında olarak ilişkilendirilebilir.

Ayrıca verifier interface aynı IDcomB commitment'ını her claim sırasında halka açık biçimde gösteriyorsa bu commitment'ın tekrar kullanıldığı bütün işlemler zincir seviyesinde birbirine bağlanabilir.

Bu nedenle kaynak, post-claim gizliliği önemseyen deployment'larda identity commitment'ın verifier interface arkasında gizlenmesini veya commitment rotasyonu yapılmasını önermektedir.

Verified-quote modelinde farklı göndericiler birbirini dolaylı olarak fark edebilir mi?

Evet. Kaynağın önemli ayrıntılarından biri budur.

Aynı binding epoch içinde aynı alıcıya ödeme yapmak isteyen farklı göndericiler quote içerisinde aynı KB,e commitment'ını görür.

Bu göndericiler iş birliği yaparsa aynı alıcıya ödeme yaptıklarını anlayabilir.

Bu bilgi blockchain'e yazılmadığı için G1 ve G2 kapsamındaki genel on-chain observer gizliliğini doğrudan bozmaz; ancak kaynak bunu cross-sender linkability olarak açık bir sınırlılık şeklinde tanımlar.

Relay Veritabanı Ele Geçirilirse Ne Olur?

HFIPay zincir üzerindeki identifier bilgisini gizler ancak relay'in özel directory'si kritik bir gizlilik katmanıdır.

Bir saldırgan relay veritabanını ele geçirirse:

Norm(e_B) → (IDcom_B, u_B,e, K_B,e, ...)

eşleşmelerini ve identifier-to-intent kayıtlarını öğrenebilir.

Daha önemlisi, geçmiş epoch handle'ları tutuluyorsa saldırgan blockchain üzerindeki eski intentId değerleri için:

H("hfipay:bind" || u_B,e || intentId)

hesaplayarak ilgili zaman aralığındaki geçmiş işlemleri geriye dönük biçimde de-anonimleştirebilir.

Kaynak bu nedenle saldırı etkisinin yalnız aktif intent'lerle sınırlı olmadığını, ele geçirilen ve hâlâ saklanan epoch'lara ait bütün geçmişe uzanabileceğini vurgulamaktadır.

Önerilen azaltma yöntemleri arasında encrypted-at-rest directory, hardware-backed keys, epoch rotasyonu, tamamlanmış epoch handle'larının silinmesi, eski intent/quote kayıtlarının temizlenmesi ve ileride relay servisinin birden fazla bağımsız operatöre dağıtılması bulunmaktadır.

Bununla birlikte relay'in ele geçirilmesi tek başına, önceden zincire doğru blinded binding ile kaydedilmiş bir intent'i saldırganın kendi adresine claim etmesine izin vermemelidir; claim hâlâ ZK-ACE ilişkisini sağlamalıdır.

HFIPay Gerçekten Merkeziyetsiz mi?

Çalışmanın mimarisi tamamen relay'siz değildir. Yazar bunu relay-assisted but non-custodial yapı olarak tanımlar.

Relay:

• identifier directory tutar,
• kullanıcıyı payment intent ile eşleştirir,
• bildirim gönderir,
• transaction relaying yapabilir,
• kullanıcı adına gas veya rent ödeyebilir.

Dolayısıyla relay bir privacy dependency ve availability dependency olmaya devam eder.

Fakat verified-quote modunda relay'in yetkisi klasik custodial “send to email” servisinden daha sınırlıdır. Relay fonları custody altında tutmaz ve intent fonlandıktan sonra doğru proof olmadan alıcıyı değiştiremez.

Üç katmanlı güven mimarisi

Zincirler Arası Ödeme Nasıl Çalışıyor?

HFIPay'in temel claim mekanizması aynı blockchain üzerinde çalışabileceği gibi kaynakta n-Vm adlı çoklu sanal makine mimarisiyle zincirler arası ödeme için de genişletilmektedir.

n-Vm, ortak bir identity layer altında birden fazla VM'nin çalıştığı Layer-1 yaklaşımı olarak tanımlanmaktadır.

Tek bir identity commitment'tan farklı ortamlar için adresler türetilebilir:

α_EVM = SHA-256("evm:" || id_com)[12:32]

α_SVM = SHA-256("svm:" || id_com)

α_BVM = SHA-256("bvm:" || id_com)

α_native = id_com

Örnek zincirler arası akış

Kaynak özellikle önemli bir sınır koymaktadır: n-Vm kullanılması external-chain deposit verification problemini ortadan kaldırmaz.

Sistem yine de kaynak zincirde gerçekten ödeme yapıldığını doğrulamak zorundadır. Bunun light-client proof, validator attestation veya eşdeğer bir yöntemle gerçekleştirilmesi gerekir.

Dolayısıyla mimari bridge güvenini tamamen yok etmiyor; bunu n-Vm konsensüs sınırına dahil etmeyi amaçlıyor.

Bitcoin de kapsanıyor mu?

Çalışma n-Vm içerisinde bir BVM modülü varsayarak Bitcoin için de kavramsal akış tanımlamaktadır.

BTC önce n-Vm deposit adresine aktarılır, ardından wBTC oluşturularak intent'e bağlanır. Alıcı claim sonrasında BTC, EVM veya SVM gibi bir hedef seçebilir.

Ancak kaynak, BVM'nin Bitcoin sidechain, optimistic rollup veya ZK Bitcoin Script doğrulaması üzerinden tam olarak nasıl gerçekleştirileceğini belirlememektedir. Bu konu gelecek çalışmaya bırakılmıştır.

HFIPay ENS ve Stealth Address Sistemlerinden Nasıl Ayrılıyor?

Çalışmanın Yöntemi ve Bulguları

Araştırma ne yaptı?

Çalışma laboratuvar deneyi veya production benchmark gerçekleştirmemiştir. Temel yöntem:

1. identifier tabanlı kripto ödemelerde gizlilik probleminin tehdit modeliyle tanımlanması,
2. relay, deterministic identity, blinded binding ve ZK authorization bileşenlerinin tek protokolde birleştirilmesi,
3. baseline ve verified-quote güven modellerinin ayrılması,
4. enumeration resistance ve pre-claim unlinkability için güvenlik deneylerinin ve proof sketch'lerin tanımlanması,
5. EVM ve Solana için uygulama taslaklarının oluşturulması,
6. n-Vm üzerinden zincirler arası uzantının açıklanmasıdır.

G1: Enumeration Resistance

Kaynakta G1 deneyi, saldırgana hedef identifier ve eşlenmiş public metadata altında yeni bir intent tuple'ı verilmesiyle tanımlanmaktadır.

Yazarın önermesine göre relay directory ele geçirilmemişse, aktif veya saklanan epoch handle'ları public veriden elde edilemiyorsa ve kullanılan hash uygun domain separation ile güvenliyse polynomial-time on-chain gözlemcisinin target recipient ile karşılaştırma recipient'ını ayırt etme avantajı ihmal edilebilir kalmalıdır.

Bu sonuç protokolün tanımladığı gözlemci modeli altındaki proof sketch'tir; çalışma bunu genel ve tam formal verification sonucu olarak sunmamaktadır.

G2: Pre-Claim Unlinkability

İkinci güvenlik deneyi, iki pre-claim intent'in aynı alıcıya mı yoksa iki farklı alıcıya mı ait olduğunu gözlemcinin ayırt edip edemeyeceğini ele almaktadır.

Her intent için bağımsız rastgele intentId kullanılması ve ρ'nın gizli handle ile bu yeni intentId'den türetilmesi sayesinde, public metadata eşitlendiğinde on-chain gözlemci açısından aynı recipient/two recipients durumlarını ayırt edecek tekrar kullanılabilir bir public yapı bulunmadığı savunulmaktadır.

Quote-to-Claim Composition

Çalışmanın Lemma 3.1'i verified-quote ile claim proof arasındaki bağlantıyı kurmaktadır.

Quote proof:

K = H("hfipay:bind-key" || u)

ve:

ρ = H("hfipay:bind" || u || intentId)

ilişkilerini sağlayan gizli bir u bulunduğunu kanıtlar.

Claim proof ise deterministik kimlikten türetilen u' değerinin aynı ρ'yı oluşturduğunu gösterir.

Yazar, kullanılan hash'in collision resistance varsayımı altında farklı u ve u' değerlerinin aynı yapılandırılmış ρ'yı oluşturmasının hash collision gerektireceğini savunmaktadır. Bu nedenle başarılı quote ve claim'in aynı epoch-scoped hidden handle'a bağlandığı sonucuna ulaşılmaktadır.

Ölçülmüş performans sonuçları var mı?

Hayır.

Makale açık biçimde aşağıdaki ölçümleri henüz raporlamamaktadır:

• end-to-end prototype benchmark,
• quote proof boyutu,
• ZK verification latency,
• gas cost,
• relay API latency,
• throughput,
• yük altında ölçeklenebilirlik.

Bu nedenle HFIPay'in pratikte klasik transferden kaç milisaniye daha yavaş olduğu, işlem başına ne kadar maliyet çıkardığı veya saniyede kaç ödeme işleyebildiği bu makaleden çıkarılamaz.

Verified-quote'un ek maliyeti

Kaynak nicel benchmark vermese de mimari ek yükü nitel olarak tanımlamaktadır.

Baseline HFIPay:

directory lookup + intent registration + recipient claim proof + on-chain proof verification

gerektirir.

Verified-quote sürümü bunlara ek olarak:

relay tarafından quote proof generation + gönderici tarafından quote verification

eklemektedir.

Göndericinin gördüğü quote materyalinin boyutu:

O(|τ_B| + |π^quote|)

claim transaction boyutu ise:

O(|π_i|)

olarak ifade edilmektedir.

Ana sınırlılıklar

1. Relay tamamen ortadan kalkmamaktadır: gizlilik, notification ve availability açısından relay bağımlılığı vardır.
2. Baseline modunda recipient substitution riski bir güven varsayımıdır.
3. Binding issuer yanlış attestation verebilir veya kullanılamaz hale gelebilir.
4. Relay directory compromise geçmiş intent'leri geriye dönük de-anonimleştirebilir.
5. Post-claim privacy daha zayıftır: aynı destination veya public ID commitment tekrar kullanılırsa bağlantı kurulabilir.
6. Verified-quote içinde aynı epoch'taki sender'lar K_B,e üzerinden aynı alıcıya ödeme yaptıklarını anlayabilir.
7. Network-layer traffic analysis kapsam dışıdır.
8. E-posta/OIDC account takeover başlangıç enrollment güvenliğini bozabilir.
9. Cross-chain deposit verification ayrı bir güven problemidir.
10. Production benchmark henüz bulunmamaktadır.

Gelecek çalışma başlıkları

Kaynak dört ana geliştirme yönü önermektedir:

• Quote-proof optimization: sender-verifiable proof'ların sıkıştırılması veya agregasyonu.
• Private directory federation: tek relay üzerindeki compromise riskini azaltmak için directory'nin bağımsız operatörlere dağıtılması.
• Proof aggregation: yüksek işlem hacmi için ZK-ACE claim proof'larının batch veya recursive verification yöntemiyle birleştirilmesi.
• Lazy first-receipt onboarding: daha önce kayıt olmamış alıcının ilk ödeme sırasında güçlü ve güvenli biçimde sisteme alınması.

Kaynak ve Yöntem Notu

Özgün başlık: HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

Yazar: Jian Sheng Wang.

Kurumsal bağlantı: Yeah LLC.

Tarih: 27 Mart 2026.

Kaynak: arXiv.

ArXiv kimliği: arXiv:2603.26970v1 [cs.CR].

Çalışma türü: Kriptografik protokol ve ödeme sistemi mimarisi.

Temel öneri: İnsan dostu identifier'lara özel relay çözümlemesi, intent-specific blinded recipient binding ve sıfır bilgi ispatlı claim authorization ile kripto ödeme.

Temel gizlilik hedefleri: Enumeration resistance ve pre-claim unlinkability.

Authorization altyapısı: ZK-ACE.

Deterministik kimlik recovery bileşeni: Va-Dar.

Cross-chain uzantısı: n-Vm.

İncelenen uygulama ortamları: EVM-compatible chains ve Solana; Bitcoin/n-Vm BVM için kavramsal uzantı.

Önemli teknik bileşenler: random 256-bit intentId, blinded binding ρ, binding-key commitment K_B,e, verified quote, CREATE2, Solana PDA, ZK claim proof, sender-authorized refund.

Hakemlik durumu: Kaynak arXiv sürümüdür; yüklenen belge hakemli bir dergi veya konferans kabul bilgisi sunmamaktadır.

Deneysel durum: Kaynak uçtan uca production prototype benchmark'ı veya nicel performans değerlendirmesi raporlamamaktadır.

Formal güvenlik sınırı: G1 ve G2 için sonuçlar tanımlanan observer model altında proof sketch niteliğindedir; çalışma bunları tam game-based cryptographic reduction olarak sunmamaktadır.

Bilimsel yorum sınırı: HFIPay'in mimarisi, insan dostu identifier ile kripto ödemede kullanılabilirlik ve gizlilik arasında yeni bir tasarım noktası önermektedir. Kaynak, sistemin pratik üretim ortamında maliyet, gecikme, yüksek yük altında performans veya güvenlik operasyonları bakımından doğrulandığını göstermemektedir.