OP_VERIFY

0x69 baytı, dilin genel amaçlı doğrulama ifadesidir. Script, OP_IF ile dallanabilir, ancak hata vermenin bir yoluna ve yığında kalandan başka bir dönüş değerine sahip değildir; bu nedenle bir sözleşme, yanıtı hesaplayıp bu komuta vererek bir koşulda ısrar eder. Şimdiye kadar yapılan neredeyse her ödeme bunlardan birinden geçti, genellikle birleşik bir opcode içinde gizli olarak.

Nasıl çalışır

OP_VERIFY yığından bir öğe çıkarır ve tek bir soru sorar: bu doğru mu?

Buradaki doğruluk, sayısal değil bayt düzeyinde bir kavramdır. Boş bir öğe yanlıştır. Bir dizi sıfır bayt da yanlıştır, negatif sıfır da: 0x80 ile biten bir sıfır dizisi. Geri kalan her şey doğru sayılır, buna 20 baytlık bir hash ya da 33 baytlık bir genel anahtar da dahildir. Öğe yanlışsa betik o anda sona erer ve onu içeren girdi geçersizdir; bu da etrafındaki işlemi geçersiz kılar. Öğe doğruysa yığına hiçbir şey geri konmaz ve değerlendirme bir sonraki opcode'a geçer.

Bu davranış, bir betiğin sırayla birkaç şeyi kontrol etmesini sağlar. Bir betik yalnızca sonunda tam olarak bir doğru değer kaldığında başarılı olur; dolayısıyla doğrulama ifadeleri olmadan her koşulun tek bir kapanış boolean'ına katlanması gerekirdi. Bunlarla bir sözleşme önce bir zaman kilidi, ardından bir hash ön imgesi, ardından bir imza talep edebilir ve ilk uyuşmazlıkta başarısız olur.

Dört opcode doğrulamayı yerleşik olarak taşır ve yalnızca bir bayt tasarrufu sağlamak için vardır: OP_EQUALVERIFY, OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY ve OP_NUMEQUALVERIFY. Bunlar yaygın durumları kapsadığı için mainnet'te tek başına bir 0x69 nadirdir.

İki opcode adında VERIFY taşır ve bu şekilde hiç davranmaz. BIP65 ile gelen OP_CHECKLOCKTIMEVERIFY ve BIP112 ile gelen OP_CHECKSEQUENCEVERIFY, önceden anlamsız olan no-op kodlarına yumuşak çatallanma ile eklendi; bu yüzden eski düğümleri memnun etmek için yığını tam buldukları gibi bırakmak zorundaydılar. İkisi de en üstteki öğeyi inceler ve koşul karşılanmadığında başarısız olur, ancak hiçbiri onu tüketmez; bu nedenle gerçek betiklerde her zaman ardından OP_DROP gelir.

Nerede görülür

Doğrulama ifadeleri, bir betiğin kanıtlaması gereken birden fazla şey olduğu her yerde toplanır.

Basit bir zaman kilitli kasa şöyle okunur: bir genel anahtar, OP_CHECKSIGVERIFY, 144 blok (yaklaşık bir gün) gibi bir gecikme, ardından OP_CHECKSEQUENCEVERIFY. Lightning'in commitment ve HTLC betikleri de aynı şekilde kurulur; bir ön imge kontrolü ile bir imza kontrolünü zincirleyerek ikisinden hiçbirinin tek başına parayı taşımaya yetmemesini sağlar. Taproot script harcamaları bu kalıba yoğun biçimde yaslanır, çünkü tapscript OP_CHECKMULTISIG yerine OP_CHECKSIGADD kullanır ve çok anahtarlı politikaları kompakt tutmak için verify biçimlerini kullanır.

Artık birkaç masaüstü cüzdanın harcama koşullarını okunabilir biçimde tanımlamak için kullandığı politika derleyicisi Miniscript bu opcode'ları sizin adınıza üretir. Doğrulama ifadelerinin elle ham betik yazmadan nasıl oluşturulduğunu görmenin en kolay yolu budur.

OP_VERIFY vs OP_RETURN

OP_VERIFY ve OP_RETURN ikisi de bir betiği kötü biçimde sona erdirir, ancak yalnızca biri önce bir soru sorar. OP_VERIFY kendisine verilen değer yanlış olduğunda başarısız olur; bu yüzden doğru bir harcama onun yanından iz bırakmadan geçer. OP_RETURN, 0x6a baytı, her çalıştırıldığında başarısız olur, hiçbir koşula bağlı değildir; tam da bu nedenle hiç harcanamayacak çıktılar oluşturmak ve bir işleme veri eklemek için kullanılır. Birincisinde ölen bir betiğe yanlış bir şey verilmiştir. İkincisinde ölen bir betik ise baştan beri harcanabilir olması hiç düşünülmemiş bir betiktir.