Otomatik Tekrar Koruması
Otomatik Tekrar Koruması, blockchain çatalları sırasında uygulanan bir güvenlik mekanizmasıdır ve işlemlerin kazara veya kötü niyetle birden fazla zincirde tekrar edilmesini önler. Bu koruma, bir zincir için tasarlanmış işlemlerin başka bir zincirde işlenemeyeceğini garanti eder.
Ana Özellikler
- İşlem izolasyonu
- Çatallama spesifik imzalar
- Otomatik uygulama
- Zincir ayrımı
Nasıl Çalışır
- İşlem İmzalama
- Benzersiz zincir tanımlayıcıları
- Değiştirilmiş imza şeması
- Çatallama spesifik parametreler
- Koruma Mekanizması
- Otomatik doğrulama
- Zincirler arası önleme
- İşlem doğrulama
Faydalar
- Çift harcama önlenir
- Kullanıcı varlıklarını korur
- Zincir bütünlüğünü korur
- Kullanıcı hatalarını azaltır
Uygulama
- Sert çatallama hazırlığı
- Ağ yükseltmeleri
- Protokol değişiklikleri
- Cüzdan uyumluluğu
İlgili Terimler
- Sert Çatallama
- Blockchain Çatallaması
- İşlem Güvenliği
- Ağ Yükseltmesi
Basitçe anlatmak gerekirse
Otomatik tekrar koruması, bir blockchain hard fork'u sonrasinda bir islemin her iki zincirde de gecerli olmasını engelleyen guvenlik ozelligi. Fork oldugunda iki ayri zincir olusur -- replay protection olmazsa A zincirindeki islem B zincirinde de gecerli olur. Bu "istenmeyen islem" riskini ortadan kaldırır.
Gercek dunya ornegini
BTC ve BCH 2017'de ayrildi (hard fork). Elinizdeki 1 BTC size hem BTC hem BCH verdi. Replay protection olmasaydi: BTC'ye X adrese coin gonderdunuz -- ayni islem BCH zincirinde de gecerli olurdu ve X adresindeki BCH de giderdi (isteğiniz disinda!). Neyse ki her iki zincirde replay protection mekanizmasi var -- islemler birbirinden bagimsiz.
SSS
S: Replay protection nasıl calisir? C: Yontemler: (1) Farkli address formati -- her zincir kendi formatını kullanir (BTC legacy vs BCH CashAddr), (2) SIGHASH type degisikligi -- islem imzasi fork'a ozgu hale getirilir, (3) OP_RETURN data -- ekstra veri ile zinciri tanımlar, (4) Chain ID -- Ethereum fork'larında standart cozum. Amaç: her islem "ben hangi zincirim?" sorusunu cevaplasın.
S: Tum fork'lar replay protection'e sahip mi? C: Degil -- bu buyuk risk faktoru. ETH/ETC split'inde baslangicta replay protection yoktu (sonra eklendi). Bazı kucuk coin fork'lari hala protection olmadan calisir. Fork islemi yapmadan once mutlaka kontrol edin. Protection olmayan fork = cift harcama riski.
S: Replay attack (tekrar saldirisi) nedir? C: Saldirgan gecerli bir islemi kopyalayarak tekrar broadcast eder. Hedef: ayni islemi tekrar gerceklestirmek (coin'i tekrar gondermek gibi). Replay protection bunu engeller. Replay attack genellikle fork senaryolarinda sorun olur -- normal (forksuz) islemlerde nadirdir.
S: Kingfisher ile ilgisi? C: Dogrudan yok. Ancak fork olaylarinda piyasa reaksiyonunu izlemek icin kullanilabilir: fork sonrasi hangi zincir daha cok islem goruyor? Likidite nerede? Funding rate ne diyor? Bu veriler hangi zincirin "kazanan" taraf oldugunu gosterebilir.
S: Kullanici olarak ne yapmaliyim? C: Fork sonrasi: (1) Replay protection olup olmadigini kontrol etmeden hicbir islem yapmayin, (2) Coin'leri her iki zincirde de ayrı cüzdanlara tasiyin, (3) Forked coin'leri sadece replay protection onayindan sonra hareket ettirin, (4) Asla fork sirasinda aktif emir birakmayin. Guvenlik = dikkat.
Ilgili terimler
- Hard Fork
- Blockchain
- Cift Harcama
- Zincir Ayrilması
Derinlemesine: ilgili makaleler
- Kingfisher Baslangic -- Blockchain guvenlik kavramları
- Piyasa Kalitesi -- Fork olaylari ve piyasa etkileri