Bitcoin sınırlama şartları: Programlanabilirliğin yeni yönü
Bitcoin topluluğu son zamanlarda OP_CAT gibi işlem kodlarının yeniden etkinleştirilmesi üzerine yoğun bir tartışma yürütüyor. Taproot Wizard, Quantum Cats NFT'lerini piyasaya sürerek ve BIP-420 numarasını aldığını iddia ederek büyük ilgi çekti. Destekçiler, OP_CAT'ın etkinleştirilmesinin "kısıtlama şartları" sağladığını ve böylece Bitcoin'e akıllı sözleşmeler ve Programlanabilirlik kazandıracağını savunuyor.
"Sınırlama Maddesi"(kovenantlar)bu kavram geliştiriciler arasında yıllardır tartışmalara yol açtı. OP_CAT'ın yanı sıra OP_CTV, APO, OP_VAULT gibi sınırlama maddelerini gerçekleştiren çeşitli teknik çözümler de bulunmaktadır. Peki, Bitcoin'in "sınırlama maddesi" nedir? Neden bu kadar geniş ve kalıcı bir ilgi uyandırabiliyor? Bitcoin'e ne gibi programlanabilirlikler kazandırabilir? Arkasındaki tasarım prensibi nedir? Bu makale bu sorulara genel bir bakış ve tartışma sunacaktır.
"Sınırlama Hükümleri" Nedir?
"Kısıtlama Şartları" ( anlaşmaları ), gelecekteki Bitcoin işlemleri için şartlar belirleyebilen bir mekanizmadır. Mevcut Bitcoin script'i, geçerli imza gerektirme, belirli şartlara uygun script sağlama gibi bazı kısıtlama şartları içermektedir. Ancak kullanıcı kilidi açabildiği sürece, UTXO'yu istediği yere harcayabilir.
Ve sınırlayıcı hükümler, bu temele ek olarak daha fazla kısıtlama getirmiştir, örneğin UTXO'nun sonraki harcama yönlerini kısıtlayarak "belirli amaçlar için kullanma" etkisini sağlamak; ya da bir işlemdeki diğer girdilerin koşullarını kısıtlamak gibi.
Daha doğru bir ifadeyle, mevcut Bitcoin script'leri de belirli kısıtlama fonksiyonlarına sahiptir, örneğin opcode tabanlı zaman kilitleri. İşlemin nLock veya nSequence alanlarını kontrol ederek, işlem harcaması öncesinde zaman kısıtlaması sağlanabilir. Ancak şu anda esasen zamanla ilgili kısıtlamalarla sınırlıdır.
Geliştiricilerin bu kısıtlamaları kontrol etme amacının yalnızca sınırlama olmadığı, aynı zamanda işlem yürütme kurallarını belirlemek olduğu. Kullanıcılar yalnızca önceden belirlenmiş kurallara göre işlemler gerçekleştirebilir, böylece planlanan iş süreçlerini tamamlayabilir.
Bu nedenle, sınırlayıcı şartlar, sezgisel olarak daha fazla uygulama senaryosunu açığa çıkarabilir.
Uygulama Senaryosu
Staking cezasını güvence altına alın
Kısıtlama koşullarına dair bir sezgisel örnek, Babylon'un Bitcoin staking'deki slash işlemi.
Babylon'un Bitcoin staking süreci, kullanıcıların BTC varlıklarını ana zincirdeki özel bir script'e göndermesidir. Harcama koşulları iki türden oluşmaktadır:
Normal son: Belirli bir süre sonra, kullanıcı kendi imzasıyla kilidi açabilir ve unstake sürecini tamamlayabilir.
Cezalandırma Bitti: Eğer kullanıcı Babylon'un güvenli PoS zincirinde çift imza gibi kötü niyetli davranışlar sergilerse, o zaman EOTS( üzerinden bir kerelik imza ) varlıkları kilidini açmak için kullanılabilir, ağdaki yürütme rolü bazı varlıkları zorla yakma adresine (slash) gönderecektir.
Buradaki "zorunlu gönderim", UTXO'nun kilidinin açılabilmesine rağmen, varlığın başka bir yere serbestçe gönderilemeyeceği, sadece yakılabileceği anlamına gelir. Bu, kötü niyetli kullanıcıların bilinen imzalarla varlıklarını geri alarak cezadan kaçmalarını engeller.
OP_CTV gibi sınırlayıcı koşullar uygulandıktan sonra, staking scriptinin "ceza bitişi" dalında ilgili opcode'lar eklenerek kısıtlama sağlanabilir.
OP_CTV etkinleştirilmeden önce, Babylon, kullanıcılar ve komite tarafından birlikte yürütülen bir geçici yöntemle kısıtlama şartlarının zorunlu uygulanmasını simüle etmelidir.
tıkanıklık kontrolü
Ağ yoğunluğu sırasında, işlem havuzunda paketlenmeyi bekleyen çok sayıda işlem birikmektedir, kullanıcıların hızlı onay almak için işlem ücretlerini artırmaları gerekmektedir. Eğer kullanıcı birden fazla işlem göndermek zorundaysa, yüksek maliyetleri üstlenmek zorunda kalır ve bu durum, ağın toplam işlem ücretlerini daha da artırır.
Sınırlayıcı maddelerle birlikte, gönderici önce bir toplu gönderim işlemi taahhüt edebilir. Bu taahhüt, tüm alıcıların nihai işlemin gerçekleştirileceğine inanmasını sağlar ve işlem ücretleri düştüğünde belirli işlemleri göndermeyi bekleyebilir.
Blok alanına olan talep çok yüksek olduğunda, işlemler pahalı hale gelir. OP_CHECKTEMPLATEVERIFY kullanarak, büyük ölçekli ödeme işleyicileri tüm ödemeleri tek bir O(1) işleminde birleştirip onaylayabilirler. Daha sonra blok alanı talebi azaldığında, bu UTXO'dan ödemeler genişletilebilir.
Bu, OP_CTV kısıtlaması tarafından önerilen tipik uygulama vakalarından biridir.
Cüzdan
(vault), Bitcoin uygulamalarında yaygın olarak tartışılan bir senaryodur, özellikle kısıtlama koşulları alanında. Günlük işlemler, fonların saklanması ve kullanım ihtiyaçları arasında bir denge gerektirir; insanlar, fonların güvenliğini garanti altına alacak, hesap hacklense bile ( özel anahtar sızdırılsa bile fon kullanımını kısıtlayacak bir tür saklama cüzdanı uygulaması istemektedir.
Sınırlı şartlar teknolojisine dayalı olarak, saklama uygulamaları kolayca oluşturulabilir.
OP_VAULT planını örnek alarak: saklama fonlarını harcarken, önce bir işlemi zincire gönderip niyetini belirtmek gerekir )"trigger"( ve koşulu ayarlamak:
Normal durum: İkinci işlem nihai para çekme işlemidir. N blok bekledikten sonra, fonlar herhangi bir adrese harcanabilir.
Anormal durum: Eğer ) numaralı bir hırsızlık işlemi veya ( numaralı bir zorla işlem tespit edilirse, N bloktaki para çekme işlemi gönderilmeden önce, fonlar hemen daha güvenli bir adrese gönderilebilir.
Dikkat edilmesi gereken bir nokta, sınırlayıcı hükümler olmasa bile, bir saklama uygulaması oluşturulabileceğidir. Bir yöntem, gelecekteki harcamalar için imzayı hazırlamak üzere özel anahtar kullanmak ve ardından özel anahtarı imha etmektir. Ancak bu yöntem hala sınırlamalara sahiptir; özel anahtarın imha edildiğinden emin olunması, miktar ve işlem ücretinin önceden belirlenmesi gibi esneklik eksiklikleri vardır.
![Covenants'in Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Sağlarız?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
) daha sağlam ve esnek durum kanalları
Durum kanalı ###, Lightning Network ( dahil olmak üzere, düğümlerin en son durumu gözlemleyebildiği ve en son durumu zincire normal bir şekilde yayınlayabildiği durumlarda, ana zincir ile neredeyse aynı güvenliğe sahip olduğu düşünülebilir. Sınırlayıcı maddeler ile bazı yeni durum kanalı tasarımları, Lightning Network temelinde daha sağlam veya esnek hale getirilebilir; en bilinenleri Eltoo, Ark gibi.
Eltoo) ayrıca LN-Symmetry( olarak adlandırılır ve tipik bir örnektir. Bu, Lightning Network için bir yürütme katmanı önerir, böylece herhangi bir sonraki kanal durumu önceki durumu değiştirebilir, ceza mekanizmasına ihtiyaç duymadan, bu nedenle Lightning Network düğümlerinin rakiplerin kötü niyetli davranışlarına karşı birçok önceki durumu saklamasını önleyebilir. Eltoo, bu etkiyi gerçekleştirmek için SIGHASH_NOINPUT imza yöntemini, yani APO)BIP-118('i önerdi.
Ark, Lightning Network'ün giriş akışını ve kanal yönetimini azaltmayı hedefliyor. Bu, belirli bir süre boyunca bir hizmet sağlayıcısını karşı taraf olarak kabul eden birden fazla kullanıcının katıldığı joinpool biçiminde bir protokoldür. Kullanıcılar, zincir dışı sanal UTXO)vUTXO( işlemleri gerçekleştirebilir, ancak maliyetleri azaltmak için zincir üzerinde bir UTXO paylaşabilirler. Cüzdan benzeri bir yapıya sahip olan Ark, mevcut Bitcoin ağı üzerinde de uygulanabilir; ancak kısıtlama maddeleri getirildiğinde, Ark işlem şablonlarına dayanarak gerekli etkileşim miktarını azaltabilir ve daha az güvene dayalı tek taraflı çıkışlar gerçekleştirebilir.
![Covenants'in Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Kısıtlama Şartları Teknik Genel Görünümü
Yukarıdaki uygulamalardan görülebileceği gibi, sınırlayıcı hükümler daha çok bir etki gibi görünmektedir, belirli bir teknoloji değil; bu nedenle çeşitli uygulama yöntemleri vardır. Aşağıdaki birkaç boyuttan sınıflandırılabilir:
Tür: Genel, Özel
Uygulama Yöntemi: Opcode Tabanlı, İmza Tabanlı
Rekürsiflik: Rekürsif, rekürsif olmayan
Bunlar arasında, geri çağırma, bazı kısıtlama koşullarının uygulanmasının, bir sonraki çıkışı kısıtlayarak bir sonraki çıkışı sınırlamak için kullanılabileceğini ve birden fazla işlemde kısıtlamaların gerçekleştirilmesini sağlar.
Ana akım kısıtlama şartları tasarımı şunları içerir:
OP_CTV: Genel tür, opcode tabanlı, rekürsif değil
APO: Genel tür, imza bazlı, özyinelemeli değil
OP_VAULT: Özel tür, opcode'a dayalı, özyinelemeli değil
OP_CAT: Genel, opcode tabanlı, yineleme ) eğer OP_CAT ile birleştirilirse (
![Covenants'ı Detaylı İnceleme: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(
Sınırlama Şartlarının Tasarımı
Mevcut Bitcoin scriptleri esas olarak kilidi açma koşulları ile sınırlıdır, UTXO'nun nasıl harcanacağı konusunda herhangi bir sınırlama yoktur. Kısıtlama şartlarını uygulamak için, mevcut scriptin bu işlevi neden yerine getiremediğini düşünmek gerekir.
Ana sebep, mevcut Bitcoin script'inin işlemin kendisinin içeriğini okuyamamasıdır, yani işlemin "iç gözlemi" )introspection(.
Eğer işlem iç gözlemi gerçekleştirilebilirse - işlemin herhangi bir içeriğini ), çıktıları ( dahil olmak üzere kontrol etmek mümkün olursa, kısıtlama şartları sağlanabilir.
Bu nedenle, sınırlayıcı hükümlerinin tasarımı esas olarak iç gözlem nasıl gerçekleştirileceği etrafında şekillenmektedir.
![Covenants Hakkında Detaylı Açıklama: Bitcoin'in Programlanabilirliğini Nasıl Sağlayabiliriz?])https://img-cdn.gateio.im/webp-social/moments-07087bfb6a80b962d13965a8a89b6c6d.webp(
) İşlem koduna dayalı vs İmza dayalı
En doğrudan düşünce, bir veya birden fazla işlem kodu ###, bir işlem kodu + birden fazla parametre veya birden fazla farklı işlevdeki işlem kodu ( eklemektir, doğrudan işlem içeriğini okumaktır. Bu, işlem koduna dayalı bir yaklaşımdır.
Başka bir yaklaşım, script içinde işlem içeriğini doğrudan okumak ve kontrol etmek yerine, işlem içeriğinin hash'ini kullanmaktır - eğer bu hash imzalanmışsa, script içinde OP_CHECKSIG gibi komutları değiştirerek bu imzayı kontrol etmek, işlem içgörü ve kısıtlama maddelerini dolaylı olarak gerçekleştirmek için yeterlidir. Bu, imzaya dayalı bir tasarım şeklidir ve esas olarak APO ve OP_CSFS gibi öğeleri içerir.
![Covenants'ın Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-5eacb98269f8d7e5b02fe936ac208702.webp(
) APO
SIGHASH_ANYPREVOUT###APO(, önerilen bir Bitcoin imzalama yöntemidir. İmzanın en basit şekli, işlemin giriş ve çıkışlarına taahhüt etmektir, ancak Bitcoin'in daha esnek bir yolu da vardır, yani SIGHASH, işlemlerdeki giriş veya çıkışlara seçici olarak taahhüt etmeyi sağlar.
APO'nun SIGHASH'ı yalnızca çıktıları imzalar, girdi kısmını imzalamaz. Bu, APO yöntemiyle imzalanmış bir işlemin, daha sonra herhangi bir koşulu karşılayan UTXO'ya eklenebileceği anlamına gelir.
Bu esneklik, APO'nun kısıtlama maddelerini gerçekleştirmesinin teorik temelidir:
Önceden bir veya daha fazla işlem oluşturabilirsiniz.
Bu işlem bilgileri ile yalnızca bir imza elde edilebilecek bir genel anahtar oluşturun.
Böylece bu genel anahtar adresine gönderilen varlıklar yalnızca önceden oluşturulmuş işlemlerle harcanabilir.
Dikkat edilmesi gereken bir nokta, bu açık anahtarın karşılık gelen bir özel anahtarı olmadığı için, bu varlıkların yalnızca önceden oluşturulmuş işlemler aracılığıyla harcanabileceğinin garanti edilmesidir. Önceden oluşturulmuş bu işlemler içinde varlıkların yönünü belirleyerek sınırlayıcı şartları gerçekleştirebiliriz.
Ethereum'un akıllı sözleşmeleriyle karşılaştırarak anlayabiliriz: akıllı sözleşmeler aracılığıyla, yalnızca belirli koşullar sağlandığında sözleşme adresinden para çekebiliriz; bu, bir EOA imzasıyla rastgele harcama yapabileceğimiz anlamına gelmez. Bu açıdan, Bitcoin imza mekanizmasının iyileştirilmesiyle bu etkiyi gerçekleştirebilir.
Ancak yukarıdaki süreçteki sorun, hesaplama sırasında döngüsel bağımlılıkların bulunmasıdır, çünkü işlem oluşturmak ve önceden imzalamak için giriş içeriğini bilmek gerekir.
APO ve SIGHASH_NOINPUT'in bu imza yöntemini uygulama anlamı, bu döngü bağımlılığı sorununu çözebilmesidir; hesaplama sırasında yalnızca )'in belirttiği ( işleminin tüm çıktısını bilmek yeterlidir.
![Covenants'ın Ayrıntılı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Sağlayabiliriz?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(
) OP_CTV
OP_CHECKTEMPLATEVERIFY###CTV(, yani BIP-119, geliştirilmiş opcode'ları kullanmıştır.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Bitcoin kısıtlama şartları: BTC'nin yeni nesil Programlanabilirlik özelliğini aç
Bitcoin sınırlama şartları: Programlanabilirliğin yeni yönü
Bitcoin topluluğu son zamanlarda OP_CAT gibi işlem kodlarının yeniden etkinleştirilmesi üzerine yoğun bir tartışma yürütüyor. Taproot Wizard, Quantum Cats NFT'lerini piyasaya sürerek ve BIP-420 numarasını aldığını iddia ederek büyük ilgi çekti. Destekçiler, OP_CAT'ın etkinleştirilmesinin "kısıtlama şartları" sağladığını ve böylece Bitcoin'e akıllı sözleşmeler ve Programlanabilirlik kazandıracağını savunuyor.
"Sınırlama Maddesi"(kovenantlar)bu kavram geliştiriciler arasında yıllardır tartışmalara yol açtı. OP_CAT'ın yanı sıra OP_CTV, APO, OP_VAULT gibi sınırlama maddelerini gerçekleştiren çeşitli teknik çözümler de bulunmaktadır. Peki, Bitcoin'in "sınırlama maddesi" nedir? Neden bu kadar geniş ve kalıcı bir ilgi uyandırabiliyor? Bitcoin'e ne gibi programlanabilirlikler kazandırabilir? Arkasındaki tasarım prensibi nedir? Bu makale bu sorulara genel bir bakış ve tartışma sunacaktır.
"Sınırlama Hükümleri" Nedir?
"Kısıtlama Şartları" ( anlaşmaları ), gelecekteki Bitcoin işlemleri için şartlar belirleyebilen bir mekanizmadır. Mevcut Bitcoin script'i, geçerli imza gerektirme, belirli şartlara uygun script sağlama gibi bazı kısıtlama şartları içermektedir. Ancak kullanıcı kilidi açabildiği sürece, UTXO'yu istediği yere harcayabilir.
Ve sınırlayıcı hükümler, bu temele ek olarak daha fazla kısıtlama getirmiştir, örneğin UTXO'nun sonraki harcama yönlerini kısıtlayarak "belirli amaçlar için kullanma" etkisini sağlamak; ya da bir işlemdeki diğer girdilerin koşullarını kısıtlamak gibi.
Daha doğru bir ifadeyle, mevcut Bitcoin script'leri de belirli kısıtlama fonksiyonlarına sahiptir, örneğin opcode tabanlı zaman kilitleri. İşlemin nLock veya nSequence alanlarını kontrol ederek, işlem harcaması öncesinde zaman kısıtlaması sağlanabilir. Ancak şu anda esasen zamanla ilgili kısıtlamalarla sınırlıdır.
Geliştiricilerin bu kısıtlamaları kontrol etme amacının yalnızca sınırlama olmadığı, aynı zamanda işlem yürütme kurallarını belirlemek olduğu. Kullanıcılar yalnızca önceden belirlenmiş kurallara göre işlemler gerçekleştirebilir, böylece planlanan iş süreçlerini tamamlayabilir.
Bu nedenle, sınırlayıcı şartlar, sezgisel olarak daha fazla uygulama senaryosunu açığa çıkarabilir.
Uygulama Senaryosu
Staking cezasını güvence altına alın
Kısıtlama koşullarına dair bir sezgisel örnek, Babylon'un Bitcoin staking'deki slash işlemi.
Babylon'un Bitcoin staking süreci, kullanıcıların BTC varlıklarını ana zincirdeki özel bir script'e göndermesidir. Harcama koşulları iki türden oluşmaktadır:
Normal son: Belirli bir süre sonra, kullanıcı kendi imzasıyla kilidi açabilir ve unstake sürecini tamamlayabilir.
Cezalandırma Bitti: Eğer kullanıcı Babylon'un güvenli PoS zincirinde çift imza gibi kötü niyetli davranışlar sergilerse, o zaman EOTS( üzerinden bir kerelik imza ) varlıkları kilidini açmak için kullanılabilir, ağdaki yürütme rolü bazı varlıkları zorla yakma adresine (slash) gönderecektir.
Buradaki "zorunlu gönderim", UTXO'nun kilidinin açılabilmesine rağmen, varlığın başka bir yere serbestçe gönderilemeyeceği, sadece yakılabileceği anlamına gelir. Bu, kötü niyetli kullanıcıların bilinen imzalarla varlıklarını geri alarak cezadan kaçmalarını engeller.
OP_CTV gibi sınırlayıcı koşullar uygulandıktan sonra, staking scriptinin "ceza bitişi" dalında ilgili opcode'lar eklenerek kısıtlama sağlanabilir.
OP_CTV etkinleştirilmeden önce, Babylon, kullanıcılar ve komite tarafından birlikte yürütülen bir geçici yöntemle kısıtlama şartlarının zorunlu uygulanmasını simüle etmelidir.
tıkanıklık kontrolü
Ağ yoğunluğu sırasında, işlem havuzunda paketlenmeyi bekleyen çok sayıda işlem birikmektedir, kullanıcıların hızlı onay almak için işlem ücretlerini artırmaları gerekmektedir. Eğer kullanıcı birden fazla işlem göndermek zorundaysa, yüksek maliyetleri üstlenmek zorunda kalır ve bu durum, ağın toplam işlem ücretlerini daha da artırır.
Sınırlayıcı maddelerle birlikte, gönderici önce bir toplu gönderim işlemi taahhüt edebilir. Bu taahhüt, tüm alıcıların nihai işlemin gerçekleştirileceğine inanmasını sağlar ve işlem ücretleri düştüğünde belirli işlemleri göndermeyi bekleyebilir.
Blok alanına olan talep çok yüksek olduğunda, işlemler pahalı hale gelir. OP_CHECKTEMPLATEVERIFY kullanarak, büyük ölçekli ödeme işleyicileri tüm ödemeleri tek bir O(1) işleminde birleştirip onaylayabilirler. Daha sonra blok alanı talebi azaldığında, bu UTXO'dan ödemeler genişletilebilir.
Bu, OP_CTV kısıtlaması tarafından önerilen tipik uygulama vakalarından biridir.
Cüzdan
(vault), Bitcoin uygulamalarında yaygın olarak tartışılan bir senaryodur, özellikle kısıtlama koşulları alanında. Günlük işlemler, fonların saklanması ve kullanım ihtiyaçları arasında bir denge gerektirir; insanlar, fonların güvenliğini garanti altına alacak, hesap hacklense bile ( özel anahtar sızdırılsa bile fon kullanımını kısıtlayacak bir tür saklama cüzdanı uygulaması istemektedir.
Sınırlı şartlar teknolojisine dayalı olarak, saklama uygulamaları kolayca oluşturulabilir.
OP_VAULT planını örnek alarak: saklama fonlarını harcarken, önce bir işlemi zincire gönderip niyetini belirtmek gerekir )"trigger"( ve koşulu ayarlamak:
Normal durum: İkinci işlem nihai para çekme işlemidir. N blok bekledikten sonra, fonlar herhangi bir adrese harcanabilir.
Anormal durum: Eğer ) numaralı bir hırsızlık işlemi veya ( numaralı bir zorla işlem tespit edilirse, N bloktaki para çekme işlemi gönderilmeden önce, fonlar hemen daha güvenli bir adrese gönderilebilir.
Dikkat edilmesi gereken bir nokta, sınırlayıcı hükümler olmasa bile, bir saklama uygulaması oluşturulabileceğidir. Bir yöntem, gelecekteki harcamalar için imzayı hazırlamak üzere özel anahtar kullanmak ve ardından özel anahtarı imha etmektir. Ancak bu yöntem hala sınırlamalara sahiptir; özel anahtarın imha edildiğinden emin olunması, miktar ve işlem ücretinin önceden belirlenmesi gibi esneklik eksiklikleri vardır.
![Covenants'in Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Sağlarız?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
) daha sağlam ve esnek durum kanalları
Durum kanalı ###, Lightning Network ( dahil olmak üzere, düğümlerin en son durumu gözlemleyebildiği ve en son durumu zincire normal bir şekilde yayınlayabildiği durumlarda, ana zincir ile neredeyse aynı güvenliğe sahip olduğu düşünülebilir. Sınırlayıcı maddeler ile bazı yeni durum kanalı tasarımları, Lightning Network temelinde daha sağlam veya esnek hale getirilebilir; en bilinenleri Eltoo, Ark gibi.
Eltoo) ayrıca LN-Symmetry( olarak adlandırılır ve tipik bir örnektir. Bu, Lightning Network için bir yürütme katmanı önerir, böylece herhangi bir sonraki kanal durumu önceki durumu değiştirebilir, ceza mekanizmasına ihtiyaç duymadan, bu nedenle Lightning Network düğümlerinin rakiplerin kötü niyetli davranışlarına karşı birçok önceki durumu saklamasını önleyebilir. Eltoo, bu etkiyi gerçekleştirmek için SIGHASH_NOINPUT imza yöntemini, yani APO)BIP-118('i önerdi.
Ark, Lightning Network'ün giriş akışını ve kanal yönetimini azaltmayı hedefliyor. Bu, belirli bir süre boyunca bir hizmet sağlayıcısını karşı taraf olarak kabul eden birden fazla kullanıcının katıldığı joinpool biçiminde bir protokoldür. Kullanıcılar, zincir dışı sanal UTXO)vUTXO( işlemleri gerçekleştirebilir, ancak maliyetleri azaltmak için zincir üzerinde bir UTXO paylaşabilirler. Cüzdan benzeri bir yapıya sahip olan Ark, mevcut Bitcoin ağı üzerinde de uygulanabilir; ancak kısıtlama maddeleri getirildiğinde, Ark işlem şablonlarına dayanarak gerekli etkileşim miktarını azaltabilir ve daha az güvene dayalı tek taraflı çıkışlar gerçekleştirebilir.
![Covenants'in Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Kısıtlama Şartları Teknik Genel Görünümü
Yukarıdaki uygulamalardan görülebileceği gibi, sınırlayıcı hükümler daha çok bir etki gibi görünmektedir, belirli bir teknoloji değil; bu nedenle çeşitli uygulama yöntemleri vardır. Aşağıdaki birkaç boyuttan sınıflandırılabilir:
Bunlar arasında, geri çağırma, bazı kısıtlama koşullarının uygulanmasının, bir sonraki çıkışı kısıtlayarak bir sonraki çıkışı sınırlamak için kullanılabileceğini ve birden fazla işlemde kısıtlamaların gerçekleştirilmesini sağlar.
Ana akım kısıtlama şartları tasarımı şunları içerir:
![Covenants'ı Detaylı İnceleme: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-a077d9a30293ef68ccb8482bfc57aeea.webp(
Sınırlama Şartlarının Tasarımı
Mevcut Bitcoin scriptleri esas olarak kilidi açma koşulları ile sınırlıdır, UTXO'nun nasıl harcanacağı konusunda herhangi bir sınırlama yoktur. Kısıtlama şartlarını uygulamak için, mevcut scriptin bu işlevi neden yerine getiremediğini düşünmek gerekir.
Ana sebep, mevcut Bitcoin script'inin işlemin kendisinin içeriğini okuyamamasıdır, yani işlemin "iç gözlemi" )introspection(.
Eğer işlem iç gözlemi gerçekleştirilebilirse - işlemin herhangi bir içeriğini ), çıktıları ( dahil olmak üzere kontrol etmek mümkün olursa, kısıtlama şartları sağlanabilir.
Bu nedenle, sınırlayıcı hükümlerinin tasarımı esas olarak iç gözlem nasıl gerçekleştirileceği etrafında şekillenmektedir.
![Covenants Hakkında Detaylı Açıklama: Bitcoin'in Programlanabilirliğini Nasıl Sağlayabiliriz?])https://img-cdn.gateio.im/webp-social/moments-07087bfb6a80b962d13965a8a89b6c6d.webp(
) İşlem koduna dayalı vs İmza dayalı
En doğrudan düşünce, bir veya birden fazla işlem kodu ###, bir işlem kodu + birden fazla parametre veya birden fazla farklı işlevdeki işlem kodu ( eklemektir, doğrudan işlem içeriğini okumaktır. Bu, işlem koduna dayalı bir yaklaşımdır.
Başka bir yaklaşım, script içinde işlem içeriğini doğrudan okumak ve kontrol etmek yerine, işlem içeriğinin hash'ini kullanmaktır - eğer bu hash imzalanmışsa, script içinde OP_CHECKSIG gibi komutları değiştirerek bu imzayı kontrol etmek, işlem içgörü ve kısıtlama maddelerini dolaylı olarak gerçekleştirmek için yeterlidir. Bu, imzaya dayalı bir tasarım şeklidir ve esas olarak APO ve OP_CSFS gibi öğeleri içerir.
![Covenants'ın Detaylı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-5eacb98269f8d7e5b02fe936ac208702.webp(
) APO
SIGHASH_ANYPREVOUT###APO(, önerilen bir Bitcoin imzalama yöntemidir. İmzanın en basit şekli, işlemin giriş ve çıkışlarına taahhüt etmektir, ancak Bitcoin'in daha esnek bir yolu da vardır, yani SIGHASH, işlemlerdeki giriş veya çıkışlara seçici olarak taahhüt etmeyi sağlar.
APO'nun SIGHASH'ı yalnızca çıktıları imzalar, girdi kısmını imzalamaz. Bu, APO yöntemiyle imzalanmış bir işlemin, daha sonra herhangi bir koşulu karşılayan UTXO'ya eklenebileceği anlamına gelir.
Bu esneklik, APO'nun kısıtlama maddelerini gerçekleştirmesinin teorik temelidir:
Dikkat edilmesi gereken bir nokta, bu açık anahtarın karşılık gelen bir özel anahtarı olmadığı için, bu varlıkların yalnızca önceden oluşturulmuş işlemler aracılığıyla harcanabileceğinin garanti edilmesidir. Önceden oluşturulmuş bu işlemler içinde varlıkların yönünü belirleyerek sınırlayıcı şartları gerçekleştirebiliriz.
Ethereum'un akıllı sözleşmeleriyle karşılaştırarak anlayabiliriz: akıllı sözleşmeler aracılığıyla, yalnızca belirli koşullar sağlandığında sözleşme adresinden para çekebiliriz; bu, bir EOA imzasıyla rastgele harcama yapabileceğimiz anlamına gelmez. Bu açıdan, Bitcoin imza mekanizmasının iyileştirilmesiyle bu etkiyi gerçekleştirebilir.
Ancak yukarıdaki süreçteki sorun, hesaplama sırasında döngüsel bağımlılıkların bulunmasıdır, çünkü işlem oluşturmak ve önceden imzalamak için giriş içeriğini bilmek gerekir.
APO ve SIGHASH_NOINPUT'in bu imza yöntemini uygulama anlamı, bu döngü bağımlılığı sorununu çözebilmesidir; hesaplama sırasında yalnızca )'in belirttiği ( işleminin tüm çıktısını bilmek yeterlidir.
![Covenants'ın Ayrıntılı Açıklaması: Bitcoin'in Programlanabilirliğini Nasıl Sağlayabiliriz?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(
) OP_CTV
OP_CHECKTEMPLATEVERIFY###CTV(, yani BIP-119, geliştirilmiş opcode'ları kullanmıştır.