HashKey Capital Araştırma Raporu: Sözleşmeler, Bitcoin'in Programlanabilirliği

Orijinal yazar: HashKey Capital Yatırım Araştırmaları Başkanı Jeffrey HU, HashKey Capital Yatırım Yöneticisi Harper LI

Son zamanlarda Bitcoin topluluğunda OP_CAT gibi opkodların yeniden etkinleştirilmesi hakkında bir tartışma dalgası yaşandı. Taproot Wizard ayrıca Quantum Cats NFT'lerini başlatarak ve BIP-420 numarasını elde ettiğini iddia ederek çok fazla ilgi çekti. Destekçiler OP_CAT'ı etkinleştirmenin sözleşmeleri uygulayabileceğini ve Bitcoin akıllı sözleşmelerini veya programlanabilirliğini gerçekleştirebileceğini iddia ediyor.

Kısıtlamalar kelimesini fark edip biraz arama yaparsanız, bunun başka bir büyük tavşan deliği olduğunu göreceksiniz. Geliştiriciler yıllardır OP_CAT'a ek olarak kısıtlama maddelerini uygulamak için OP_CTV, APO, OP_VAULT ve diğer tekniklerin olduğunu tartışıyorlar.

Peki, Bitcoin'in kısıtlamaları tam olarak nelerdir? Neden yıllardır geliştiricilerin bu kadar dikkatini ve tartışmasını çektiler? Bitcoin ne tür bir programlanabilirlik elde edebilir? Bunun ardındaki tasarım ilkeleri nelerdir? Bu makale bir genel bakış ve tartışma sunmayı amaçlamaktadır.

Kısıtlama maddesi nedir?

Çince'de kısıtlayıcı maddeler olarak tercüme edilen ve bazen de sözleşme olarak tercüme edilen sözleşmeler, gelecekteki Bitcoin işlemleri için koşullar belirleyebilen bir mekanizmadır.

Mevcut Bitcoin betiği, yasal bir imza girmek ve harcama yaparken eşleşen bir betik girmek gibi kısıtlayıcı koşullar da içerir. Ancak, kullanıcı kilidini açabildiği sürece, UTXO'yu istediği yerde harcayabilir.

Kısıtlayıcı şartlar, bu kısıtlamanın nasıl kaldırılacağına bağlı olarak daha fazla kısıtlama yapmaktır; örneğin, UTXO'dan sonra harcamaları sınırlamak, yani özel amaçlar için teminat fonlarına benzer bir etki elde etmek; veya bir işlemde gönderilen diğer girdi koşulları.

Daha doğrusu, mevcut Bitcoin betiklerinde de, işlemlerin nLock veya nSequence alanlarını inceleyerek işlemler harcanmadan önce zaman sınırlamaları uygulayan opcode tabanlı zaman kilitleri gibi belirli kısıtlamalar vardır, ancak bunlar temelde zaman sınırlamalarıyla sınırlıdır.

Peki geliştiriciler ve araştırmacılar bu kısıtlama kontrollerini neden tasarlıyor? Çünkü kısıtlama maddeleri yalnızca kısıtlama uğruna değil, aynı zamanda işlem yürütme kurallarını da belirler. Bu şekilde, kullanıcılar yalnızca önceden belirlenmiş kurallara göre işlem yürüterek önceden belirlenmiş iş sürecini tamamlayabilirler.

Yani mantığa aykırı olan şey, bunun daha fazla uygulama senaryosunun kilidini açabilmesidir.

Uygulama Senaryosu

Staking Cezalarının Sağlanması

Kısıtlayıcı maddelerin en sezgisel örneklerinden biri, Babylon'un Bitcoin staking sürecindeki eğik çizgi işlemleridir.

Babylons Bitcoin staking süreci, kullanıcıların BTC varlıklarını ana zincirdeki özel bir betiğe göndermesidir. Harcama koşulları iki türü içerir:

• Mutlu son: Belirli bir süre sonra kullanıcı kendi imzasıyla kilidini açabilir ve unstake işlemini tamamlayabilir

• Kötü son: Bir kullanıcı Babylon tarafından kiralanan bir PoS zincirinde çift imzalı veya başka kötü niyetli davranışlarda bulunursa, EOTS (çıkarılabilir tek seferlik imzalar) aracılığıyla varlıkların bu kısmı açılabilir ve ağdaki yönetici rolü varlıkların bir kısmının yakıcı adrese (eğik çizgi) gönderilmesini zorlar.

Kaynak: Bitcoin Staking: Proof-of-Stake Ekonomisini Güvence Altına Almak İçin 21 Milyon Bitcoin'in Kilidini Açmak

Burada zorunlu gönderime dikkat edin, bu UTXO kilidi açılsa bile varlığın istenildiği zaman başka bir yere gönderilemeyeceği ve yalnızca yakılabileceği anlamına gelir. Bu, kötü niyetli kullanıcıların cezadan kurtulmak için varlıkları önceden kendilerine geri aktarmak için bilinen imzalarını kullanamamalarını sağlar.

Bu fonksiyon, OP_CTV gibi kısıtlayıcı terimler uygulandıktan sonra uygulanırsa, kısıtlamaları uygulamak için OP_CTV gibi opkodlar, staking betiğinin kötü sonlanan dalına eklenebilir.

OP_CTV etkinleştirilmeden önce, Babylon'un kısıtlayıcı maddelerin uygulanmasının etkisini simüle etmek için kullanıcılar ve komitenin birlikte uyguladığı bir geçici çözüm yöntemi kullanması gerekiyordu.

Tıkanıklık Kontrolü

Genel olarak, tıkanıklık, Bitcoin ağındaki işlem ücreti oranının çok yüksek olması durumunda, işlem havuzunda paketlenmeyi bekleyen çok sayıda işlem olması anlamına gelir; bu nedenle kullanıcılar işlemleri hızlı bir şekilde onaylamak istiyorlarsa işlem ücretini artırmaları gerekir.

Bir kullanıcının birden fazla alıcıya birden fazla işlem göndermesi durumunda, işlem ücretini artırmak ve nispeten yüksek maliyetlere katlanmak zorunda kalacak, bu da tüm ağın işlem ücreti oranını daha da artıracaktır.

Kısıtlamalar varsa, bir çözüm göndericinin önce bir toplu işlem yapmasıdır. Bu taahhüt tüm alıcıların son işlemin gerçekleştirileceğine inanmasını sağlayabilir ve belirli işlemi göndermeden önce işlem ücreti oranının düşük olmasını bekleyebilirler.

Aşağıdaki şekilde gösterildiği gibi, blok alanı talebi yüksek olduğunda, işlem yapmak çok pahalı hale gelir. OP_CHECKTEMPLATEVERIFY kullanarak, yüksek hacimli ödeme işlemcileri tüm ödemelerini onay için tek bir O(1) işleminde toplayabilir. Daha sonra, bir süre sonra, blok alanı talebi azaldığında, ödemeler bu UTXO'dan genişletilebilir.

Kaynak: https://utxos.org/uses/scaling/

Bu senaryo, OP_CTV kısıtlama maddesi tarafından önerilen tipik bir uygulama durumudur. Daha fazla uygulama durumu https://utxos.org/uses/ adresinde bulunabilir. Yukarıdaki tıkanıklık kontrolüne ek olarak, web sayfası Soft Fork Bahisleri, Merkezi Olmayan Seçenekler, Sürücü Zincirleri, Toplu Kanallar, Etkileşimsiz Kanallar, Güvensiz Koordinasyonsuz Madencilik Havuzları, Kasalar, Daha Güvenli Karma Zaman Kilitli Sözleşmeler (HTLCS) Sınırları vb. listeler.

Kasa

Kasalar, özellikle kısıtlamalar alanında Bitcoin uygulamalarında yaygın olarak tartışılan bir uygulama senaryosudur. Günlük işlemler kaçınılmaz olarak fonları tutma ve fonları kullanma ihtiyacını dengelemek zorunda olduğundan, insanlar fonların güvenliğini sağlayabilen ve hatta hesap hacklense bile (özel anahtar sızdırılsa bile) fonların kullanımını kısıtlayabilen bir tür kasa uygulamasına sahip olmayı ummaktadır.

Kısıtlama maddelerinin uygulanması teknolojisine dayanarak, kasa benzeri uygulamalar nispeten kolay bir şekilde oluşturulabilir.

Örnek olarak OP_VAULT tasarımını ele alalım: kasadaki fonları harcarken, önce zincire bir işlem gönderilmesi gerekir. Bu işlem kasayı harcama niyetini, yani tetikleyiciyi belirtir ve içindeki koşulları ayarlar:

• Her şey yolunda giderse, ikinci işlem son çekim işlemidir. N blok beklendikten sonra, fonlar herhangi bir yerde harcanabilir.

• Bu işlemin çalındığı (veya bir saldırı sırasında zorlandığı) keşfedilirse, N bloğun çekilme işlemi gönderilmeden önce, derhal başka bir güvenli adrese (kullanıcı tarafından daha güvenli bir şekilde saklanması için) gönderilebilir.

OP_VAULT işlemi, kaynak: BIP-345

Bir kasa uygulamasının kısıtlamalar olmadan oluşturulabileceği unutulmamalıdır. Uygulanabilir bir yol, imzayı gelecekteki harcamalar için hazırlamak için özel anahtarı kullanmak ve ardından özel anahtarı imha etmektir. Ancak, özel anahtarın imha edildiğinden emin olma gereksinimi (sıfır bilgi kanıtındaki güvenilir kurulum sürecine benzer), tutar ve işlem ücretinin önceden belirlenmesi (önceden imza nedeniyle) ve dolayısıyla esneklik eksikliği gibi hala birçok kısıtlama vardır.

OP_VAULT ve önceden imzalanmış kasa işlemlerinin karşılaştırılması, kaynak: BIP-345

Daha sağlam ve esnek devlet kanalları

Lightning Network dahil olmak üzere durum kanallarının ana zincirle hemen hemen aynı güvenliğe sahip olduğuna genel olarak inanılabilir (düğümlerin en son durumu gözlemleyebilmesi ve en son durumu zincire normal şekilde yayınlayabilmesi koşuluyla). Ancak, kısıtlamalarla birlikte, bazı yeni durum kanalı tasarım fikirleri Lightning Network'ün üstünde daha sağlam veya esnek olabilir. Bunlar arasında, daha iyi bilinenler arasında Eltoo, Ark vb. bulunur.

Eltoo (aynı zamanda LN-Symmetry olarak da bilinir) tipik bir örnektir. Bu teknik çözüm L2'nin eş anlamlısını alır ve Lightning Network için bir yürütme katmanı önererek, herhangi bir sonraki kanal durumunun bir ceza mekanizmasına ihtiyaç duymadan önceki durumu değiştirmesine izin verir. Bu nedenle, Lightning Network düğümlerinin rakiplerin kötülük yapmasını önlemek için birden fazla önceki durumu kaydetmesi ihtiyacını da ortadan kaldırabilir. Yukarıdaki etkiyi elde etmek için Eltoo, SIGHASH_NOINPUT imza yöntemini, yani APO'yu (BIP-118) önerdi.

Ark, Lightning Network'ün gelen likidite ve kanal yönetiminin zorluğunu azaltmayı hedefler. Birden fazla kullanıcının belirli bir zaman dilimi içinde bir hizmet sağlayıcıyı karşı taraf olarak kabul edip sanal UTXO (vUTXO) off-chain ticareti yapabileceği, ancak maliyetleri azaltmak için bir UTXO'yu on-chain paylaşabileceği bir joinpool tarzı protokoldür. Kasaya benzer şekilde Ark, mevcut Bitcoin ağında da uygulanabilir; ancak kısıtlamalar getirildikten sonra Ark, işlem şablonuna göre gereken etkileşim miktarını azaltabilir ve daha güvenilmez tek taraflı bir çıkış elde edebilir.

Kısıtlamaların Teknik Genel Görünümü

Yukarıdaki uygulamalardan, kısıtlama maddelerinin belirli bir teknolojiden çok bir etkiye benzediğini görebiliriz, bu yüzden bunları uygulamanın birçok teknik yolu vardır. Sınıflandırılırlarsa şunları içerebilirler:

• Tür: genel amaçlı, özel amaçlı

• Uygulama yöntemi: İşlem kodu tabanlı, imza tabanlı

• Tekrarlama: tekrarlayıcı, tekrarlayıcı olmayan

Tekrarlama, bazı kısıtlayıcı maddeler uygulanırsa, bir sonraki işlemin çıktısının bir sonraki çıktıyı kısıtlayarak kısıtlanabileceği anlamına gelir. Eklenen kısıtlamalar bir işlemin ötesine geçebilir ve daha yüksek bir işlem derinliğine ulaşabilir.

Bazı popüler kısıtlama maddesi tasarımları şunlardır:

* Özyineleme: OP_CAT ile birleştirilirse

Kısıtlama maddelerinin tasarımı

Önceki girişten, mevcut Bitcoin betiğinin esas olarak kilidi açma koşullarını kısıtladığını, ancak UTXO'nun nasıl daha fazla harcanabileceğini kısıtlamadığını görebiliriz. Kısıtlama maddesini uygulamak için, bunu tersten düşünmeliyiz: Mevcut Bitcoin betiği kısıtlama maddesini neden uygulayamıyor?

Bunun temel nedeni, mevcut Bitcoin betiğinin, işlemin içeriğini, yani işlemin iç gözlemini okuyamamasıdır.

Eğer işlemlerin iç gözlemini (bir işlemin herhangi bir içeriğini (çıktılar dahil) incelemeyi) uygulayabilirsek, o zaman kısıtlamaları da uygulayabiliriz.

Dolayısıyla kısıtlayıcı cümlelerin tasarım fikirleri de esas olarak iç gözlemin nasıl gerçekleştirileceği etrafında döner.

İşlem kodu tabanlı ve imza tabanlı

En basit ve en kaba fikir, işlem içeriğini doğrudan okumak için bir veya daha fazla opkod (yani bir opkod + birden fazla parametre veya farklı işlevlere sahip birden fazla opkod) eklemektir. Bu da opkod fikrine dayanmaktadır.

Başka bir fikir, komut dosyasındaki işlem içeriğini doğrudan okuyup kontrol etmek yerine işlem içeriğinin karmasını kullanmaktır. Karma imzalanmışsa, komut dosyası imzayı kontrol etmek için değiştirildiği sürece, örneğin OP_CHECKSIG, işlem iç gözlemi ve kısıtlama maddeleri dolaylı olarak uygulanabilir. Bu fikir, imzaların tasarım yöntemine dayanmaktadır. Esas olarak APO ve OP_CSFS'yi içerir.

APO

SIGHASH_ANYPREVOUT (APO), önerilen bir Bitcoin imza yöntemidir. İmzalamanın en basit yolu, bir işlemin hem girdisine hem de çıktısına taahhüt etmektir, ancak Bitcoin'in daha esnek bir yöntemi vardır, SIGHASH, bir işlemin girdisine veya çıktısına seçici olarak taahhüt eder.

SIGHASH'ın mevcut imza aralığı ve işlem girişi ve çıkışı için kombinasyonu (Kaynak: Mastering Bitcoin, 2.

Yukarıdaki şekilde gösterildiği gibi, tüm verilere uygulanabilen ALL'a ek olarak, NONE imza yöntemi yalnızca tüm girdilere uygulanabilir, çıktılara değil; SINGLE buna dayanır ve yalnızca aynı girdi sıra numarasına sahip çıktılara uygulanabilir. Ayrıca, SIGHASH da birleştirilebilir ve ANYONECANPAY değiştiricisi üst üste bindirildikten sonra yalnızca bir girdiye uygulanabilir.

Ancak, APO'lar SIGHASH yalnızca çıktıyı imzalar, girişi değil. Bu, APO ile imzalanmış bir işlemin koşulları karşılayan herhangi bir UTXO'ya eklenebileceği anlamına gelir.

Bu esneklik, APO uygulama kısıtlama maddesinin teorik temelini oluşturur:

• Bir veya daha fazla işlem önceden oluşturulabilir

• Bu işlemlere ait bilgiler kullanılarak yalnızca bir imza üretebilen bir açık anahtar oluşturulur.

• Bu şekilde, açık anahtar adresine gönderilen herhangi bir varlık yalnızca önceden oluşturulmuş işlemler aracılığıyla harcanabilir.

Bu genel anahtarın karşılık gelen bir özel anahtarı olmadığından, bu varlıkların yalnızca önceden oluşturulmuş işlemler aracılığıyla harcanabileceğini garanti edebileceğini belirtmekte fayda var. Daha sonra, bu önceden oluşturulmuş işlemlerdeki varlıkların hedefini belirleyebilir ve böylece kısıtlama maddelerini uygulayabiliriz.

Bunu Ethereum'un akıllı sözleşmeleriyle karşılaştırarak daha iyi anlayabiliriz: akıllı sözleşmeler aracılığıyla, EOA imzasıyla keyfi bir şekilde harcamak yerine, yalnızca belirli koşullar karşılandığında sözleşme adresinden para çekebiliriz. Bu bakış açısından, Bitcoin imza mekanizmasını iyileştirerek bu etkiyi elde edebilir.

Yukarıdaki işlemdeki sorun, işlemin önceden imzalanması ve oluşturulması için girdi içeriğinin bilinmesi gerektiğinden, hesaplamada dairesel bir bağımlılığın olmasıdır.

Bu imza yöntemini APO ve SIGHASH_NOINPUT ile uygulamanın önemi, dairesel bağımlılık sorununu çözebilmesidir. Hesaplama yaparken, yalnızca işlemin tüm çıktılarını bilmeniz (belirtmeniz) gerekir.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV) veya BIP-119, Opcode'a gelişmiş bir yaklaşım getirir. Parametre olarak bir taahhüt karması alır ve opcode'u yürüten herhangi bir işlemin bu taahhütle eşleşen bir çıktı kümesi içermesini gerektirir. CTV ile Bitcoin kullanıcılarının Bitcoin'i nasıl kullandıklarını kısıtlamalarına izin verilecektir.

Öneri başlangıçta OP_CHECKOUTPUTSHASHVERIFY (COSHV) adı altında tanıtıldı ve başlangıçta tıkanıklık kontrollü işlemler yaratma yeteneğine odaklandı, bu nedenle öneriye yönelik eleştiriler de çözümün yeterince genel olmaması ve tıkanıklık kontrolü kullanım durumuna çok özel olması gerçeğine odaklandı.

Yukarıda belirtilen tıkanıklık kontrolü kullanım durumunda, gönderici Alice 10 çıktı oluşturabilir ve bu 10 çıktıyı karma hale getirebilir ve ortaya çıkan özeti COSHV içeren bir tapleaf betiği oluşturmak için kullanabilir. Alice ayrıca katılımcıların genel anahtarlarını kullanarak Taproot betiği yolunu ifşa etmeden harcamalarda işbirliği yapmalarına olanak tanıyan bir Taproot dahili anahtarı oluşturabilir.

Alice daha sonra her alıcıya 10 çıktının birer kopyasını verir, böylece her biri Alice'in kurulum işlemini doğrulayabilir. Daha sonra bu ödemeyi harcamak istediklerinde, herhangi biri taahhüt edilen çıktıyı içeren bir işlem oluşturabilir.

Süreç boyunca Alice kurulum işlemini oluşturup gönderdiğinde, Alice bu 10 çıktı kopyasını e-posta veya bulut sürücüleri gibi mevcut asenkron iletişim yöntemleri aracılığıyla gönderebilir. Bu, alıcıların çevrimiçi olmaları veya birbirleriyle etkileşime girmeleri gerekmediği anlamına gelir.

Kaynak: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

APO'ya benzer şekilde, harcama koşullarına göre adresler de oluşturulabilir ve kilitler farklı şekillerde yapılabilir; bunlara başka anahtarlar eklemek, zaman kilitleri ve birleştirilebilir mantık dahildir.

Kaynak: https://twitter.com/OwenKemeys/status/1741575353716326835

CTV, buna dayanarak, karma harcama işleminin tanıma uyup uymadığının kontrol edilebileceğini, yani işlem verilerinin kilidi açmak için anahtar olarak kullanılabileceğini önermiştir.

Yukarıdaki 10 alıcı örneğini genişletebiliriz. Alıcı, adres anahtarını bir sonraki alıcı adres grubuna göndermek için imzalanmış ancak yayınlanmamış bir tx olarak ayarlayabilir ve böylece aşağıdaki şekilde gösterildiği gibi bir ağaç yapısı oluşturabilir. Alice, zincirde yalnızca 1 utxo blok alanı kullanarak birden fazla kullanıcıyı içeren bir hesap bakiyesi değişikliği oluşturabilir.

Kaynak: https://twitter.com/OwenKemeys/status/1741575353716326835

Yapraklardan biri yıldırım kanalı, soğuk depolama veya başka bir ödeme yoluysa ne olur? O zaman ağaç tek boyutlu ve çok katmanlı bir harcama ağacından çok boyutlu ve çok katmanlı bir harcama ağacına genişleyecek ve destekleyebileceği senaryolar daha zengin ve daha esnek olacaktır.

Kaynak: https://twitter.com/OwenKemeys/status/1744181234417140076

Teklifinden bu yana CTV, 2019'da COSHV'den yeniden adlandırıldı, 2020'de BIP-119 olarak atandı ve CTV'yi destekleyen sözleşmeler oluşturmak için programlama dili Sapio ortaya çıktı. 2022 ve 2023'te toplulukta çok sayıda tartışma ve güncelleme aldı ve ayrıca aktivasyon planı hakkında tartışmalar oldu. Toplulukta daha fazla tartışılan yumuşak çatal yükseltme tekliflerinden biri olmaya devam ediyor.

OP_KED

Başta da belirtildiği gibi, OP_CAT da oldukça popüler bir yükseltme önerisidir. Yığındaki iki öğeyi birleştirme işlevini uygular. Basit görünse de, OP_CAT betikte birçok işlevi esnek bir şekilde uygulayabilir.

En doğrudan örnek, merkle ağacıyla ilgili işlemdir. Merkle ağacı, önce birleştirilen ve sonra karıştırılan iki öğe olarak anlaşılabilir. Şu anda Bitcoin betiğinde OP_SHA 256 gibi karma işlem kodları vardır, bu nedenle OP_CAT iki öğeyi birleştirmek için kullanılabiliyorsa, merkle ağacı doğrulama işlevi betiğe uygulanabilir, bu da belirli bir ölçüde hafif istemci doğrulaması yeteneğine sahip olduğu anlamına gelir.

Diğer uygulama temeli Schnorr imzasının geliştirilmesini de içerir: betiğin harcama imza koşulu, kullanıcıların genel anahtarı ve genel nonce'unun birleştirilmesi olarak ayarlanabilir; imzalayan kişi fonları başka bir yerde harcamak için başka bir işlem imzalamak isterse, aynı nonce'u kullanmak zorundadır, bu da özel anahtarın sızdırılmasına yol açacaktır. Yani, nonce'a olan bağlılık OP_CAT aracılığıyla elde edilir, böylece imzalanan işlemin geçerliliği garanti altına alınır.

OP_CAT'in diğer uygulama senaryoları şunlardır: Bistream, ağaç imzası, kuantum dirençli Lamport imzası, kasa, vb.

OP_CAT'in kendisi yeni bir özellik değil. Bitcoin'in en eski sürümlerinde mevcuttu ancak saldırılar tarafından istismar edilebileceği için 2010'da devre dışı bırakıldı. Örneğin, OP_DUP ve OP_CAT'in tekrar tekrar kullanılması, bu demo'da gösterildiği gibi, bu tür betikleri işlerken tam bir düğümün yığınının kolayca patlamasına neden olabilir.

Ancak OP_CAT şimdi yeniden etkinleştirilirse yukarıda belirtilen yığın patlaması sorunu ortaya çıkmaz mı? Çünkü mevcut OP_CAT teklifi yalnızca tapscript'te etkinleştirmeyi içeriyor ve tapscript her yığın öğesini en fazla 520 baytla sınırlıyor, bu da önceki yığın patlaması sorununa neden olmayacak. Bazı geliştiriciler ayrıca Nakamoto'nun OP_CAT'i doğrudan devre dışı bırakmasının çok sert olabileceğini düşünüyor. Ancak OP_CAT'in esnekliği nedeniyle, şu anda tüketilemeyen güvenlik açıklarına yol açabilecek bazı uygulama senaryoları olabilir.

Bu nedenle, uygulama senaryoları ve potansiyel riskler göz önüne alındığında, OP_CAT son zamanlarda çok fazla ilgi gördü ve ayrıca PR incelemesinden geçti. Şu anda en popüler yükseltme önerilerinden biridir.

Çözüm

Öz disiplin özgürlük getirir. Yukarıdaki girişten, kısıtlama maddelerinin, işlemin daha fazla harcanmasını sınırlamak için doğrudan Bitcoin betiğine uygulanabileceğini ve böylece akıllı sözleşmelerin etkisine benzer işlem kurallarının gerçekleştirilebileceğini görebiliriz. BitVM gibi zincir dışı yöntemlerle karşılaştırıldığında, bu programlama yöntemi Bitcoin üzerinde daha doğal olarak doğrulanabilir ve ayrıca ana zincirdeki uygulamaları (tıkanıklık kontrolü), zincir dışı uygulamaları (durum kanalları) ve diğer yeni uygulama yönlerini (hisse cezaları, vb.) iyileştirebilir.

Kısıtlama uygulama teknolojisi bazı temel yükseltmelerle birleştirilebilirse, programlanabilirliğin potansiyelini daha da açığa çıkaracaktır. Örneğin, 64 bitlik operatörler için teklif gözden geçirmek son zamanlarda önerilen OP_TLUV veya diğer kısıtlama maddeleriyle birleştirilerek işlem çıktısındaki satoshi sayısına göre programlama yapılabilir.

Ancak, kısıtlamalar bazı planlanmamış suistimallere veya boşluklara da yol açabilir, bu nedenle topluluk bu konuda dikkatlidir. Ek olarak, kısıtlamaların yükseltilmesi aynı zamanda fikir birliği kurallarının yumuşak çatallı bir yükseltmesini gerektirir. Taproot yükseltmesi sırasındaki durum göz önüne alındığında, kısıtlamaların yükseltilmesinin tamamlanması da biraz zaman alabilir.

Bu makaleyi inceleyip önerilerde bulundukları için Ajian, Fisher ve Ben'e teşekkürler!

Referanslar
https://utxos.org/

https://bitcoincovenants.com/

Antlaşmalarla ilgili kaynakların bir koleksiyonu:

https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345: OP_VAULT Teklifi: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/ Kadın

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https://maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

OP_CAT:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md

CAT ve Schnorr Hileleri: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Bu makale internetten alınmıştır: HashKey Capital Araştırma Raporu: Sözleşmeler, Bitcoin'in Programlanabilirliği

İlgili: Meme Coin BONK, Ayı İşaretleri Arasında 50% Düşüşüne Maruz Kalabilir

Özetle Bonk fiyatı alçalan bir kamada ve alt trend çizgisi muhtemelen tekrar test edilecek. Bu, daha geniş piyasa ipuçlarının desteklediği olası bir 50% düşüşüne yol açabilir. BONK sahipleri ayrıca Fonlama oranları oldukça negatif olduğundan bir fiyat düşüşüne bahse giriyorlar. Bonk, meme coin'in daha fazla düşüşten kurtulmasıyla sonuçlanacak önemli bir direnç trend çizgisini aşamadı. Ancak, BONK'un sıkıştığı alçalan kama göz önüne alındığında, başka bir düşüşü garantiliyor. Bu duygu, meme coin'e kısa bahis koyan yatırımcılar tarafından da paylaşılıyor. Bonk Fonlama Oranı Tekrar Düştü Yazının yazıldığı sırada, Bonk'un fiyatı $0.00002153'lük önemli bir destek çizgisinin üzerinde. Bu seviye geçmişte birçok kez test edildi, ancak bu sefer, ...