Sözlük / Geliştirici başvuru kaynağı
OP_CHECKSIG
- OP_CHECKSIG nedir?
- OP_CHECKSIG yığından bir genel anahtar ile bir imza alır ve imzanın bu işleme bağlı olduğunu doğrular; bitcoinlerin size ait olduğunu gerçekten kanıtlayan kontrol budur.
Şimdiye kadar harcanan neredeyse her Bitcoin bu tek işlem kodundan, 0xac baytından geçti. İmzanın sonuna eklenmiş sighash baytına göre işlemin bir özetini oluşturur, imzayı genel anahtarla kontrol eder ve doğru ya da yanlış değerini yığına iter. Yanlış değerini iterse harcama gerçekleşmez; kodda Bitcoin sahibi olmanın anlamı bütünüyle budur.
Nasıl çalışır
OP_CHECKSIG iki öğeyi yığından çeker, önce genel anahtarı, altından da imzayı, sonra insanların genellikle tek bir işe indirgediği üç ayrı görevi yerine getirir.
Önce neyin imzalandığına karar verir. Bir imzanın son baytı imzanın parçası değildir: özetin işlemin hangi bölümlerini kapsadığını söyleyen bir bayraktır. Ezici çoğunluktaki değer 0x01'dir, yani tüm girdiler ve tüm çıktılar; bu nedenle imzalandıktan sonra işlemin herhangi bir bölümünü değiştirmek işlemi geçersiz kılar. Bu özeti oluşturma tarifi iki kez değiştirildi: SegWit sürüm 0 harcamaları için BIP-143 ile ve Taproot için yeniden BIP-341 ile; her ikisinde de hash maliyetinin işlem boyutunun karesiyle büyümesini durdurmak için.
İkinci olarak kodlamayı kontrol eder ve Bitcoin burada alışılmadık derecede katıdır. Eski tip bir imza geçerli DER olmalı, bayrak baytı dahil en fazla 72 bayt olmalı ve S değeri eğri mertebesinin alt yarısında bulunmalıdır. Katı kodlama kuralı Temmuz 2015'te BIP-66 ile geldi ve geçiş, birkaç büyük havuzun doğrulamadıkları blok başlıkları üzerine inşa etmesi yüzünden tek bir öğleden sonrada altı bloğu sahipsiz bıraktı. Bu, madenciliğin ve doğrulamanın farklı işler olduğunun hâlâ en açık göstergesidir.
Üçüncü olarak doğrular. Eski tip ve SegWit sürüm 0 harcamaları secp256k1 üzerinde ECDSA kullanır. Tapscript bunun yerine BIP-340 kapsamında 64 baytlık bir Schnorr imzası kullanır, başarısız bir kontrolün başka bir şey yerine boş bir öğe itmesini şart koşar ve kontrol edilen her imza için betiğe 50 ağırlık birimi bütçe yazar.
Nerede görülür
OP_CHECKSIG var olan neredeyse her betiği kapatır. Eski tip bir çıktı onunla biter, yerel tek anahtarlı bir SegWit harcaması aynı son işlem koduyla aynı şablonu çalıştırır, oysa bu baytlar zincirde hiç görünmez, Lightning'in taahhüt betikleri de zaman kilidi ve iptal dallarından sonra onunla biter.
Bir blok gezginini okurken istisnayı bilmekte yarar var. Taproot anahtar yolu harcaması hiçbir betik çalıştırmaz: düğüm tek bir imzayı doğrudan çıktıdaki 32 baytlık anahtara karşı kontrol eder. Gösterilecek bir derleme ve işaret edilecek bir işlem kodu yoktur; bu harcama türünün mevcut en ucuz ve en gizli tür olmasının ve yalnızca sahibi tarafından harcanan bir bc1p adresinin zincirde herhangi bir diğerine tamamen aynı görünmesinin nedeni tam da budur.
OP_CHECKSIG vs OP_CHECKSIGADD
OP_CHECKSIGADD, OP_CHECKSIG sayılamadığı için vardır. Çok taraflı bir betikte sunulan imzaların kaçının geçerli olduğunu bilmeniz gerekir ve eski tasarım bunu bir anahtar ve imza listesinin tamamını tek seferde yutan tek bir işlem koduyla yanıtlıyordu. Tapscript bunun yerine bir imzayı doğrulayan ve yığındaki çalışan bir toplama bir ekleyen bir işlem kodu getirdi; böylece 2/3 politikası 2 ile bir karşılaştırmayla biten kısa bir diziye dönüşür. Değişiklik kozmetik değildir: imzaları tek tek saymak, Schnorr imzalarının toplu olarak doğrulanmasını mümkün kılan şeydir ve Taproot'un doğrulama hızı bu toplu doğrulamadan gelir.