Son dönemde Bitcoin topluluğu, OP_CAT gibi işlem kodlarının yeniden kullanılmasını tartışmaya açtı. Taproot Wizard, Quantum Cats NFT'yi piyasaya sürerek ve BIP-420 numarasını aldığını iddia ederek birçok kişinin dikkatini çekti. Destekçiler, OP_CAT'in etkinleştirilmesinin "kısıtlama şartları" sağladığını ve böylece Bitcoin'in akıllı sözleşmeler veya programlanabilirlik elde edebileceğini savunuyor.
Eğer "sınırlama şartları" terimini fark ederseniz ve biraz araştırma yaparsanız, bunun başka bir büyük tavşan deliği olduğunu göreceksiniz. Geliştiriciler, OP_CAT dışında OP_CTV, APO, OP_VAULT gibi sınırlama şartlarını uygulayan teknolojileri yıllardır tartışıyor.
Peki, Bitcoin'in "kısıtlama şartları" tam olarak nedir? Neden bu kadar çok geliştiricinin yıllarca süren dikkatini ve tartışmasını çekiyor? Bitcoin'in hangi programlanabilirliklerini gerçekleştirebilir? Arka plandaki tasarım prensipleri nasıldır? Bu makale, genel bir tanıtım ve tartışma yapmayı denemektedir.
"Sınırlayıcı Şartlar" nedir
Sınırlamalar (Taahhütler ), gelecekteki Bitcoin işlemlerine şartlar koyabilen bir mekanizmadır.
Mevcut Bitcoin script'i, harcama sırasında geçerli bir imza girmeyi, uygun bir script sağlamayı gerektiren kısıtlayıcı koşulları da içerir. Ancak kullanıcı kilidi açabildiği sürece, bu UTXO'yu istediği herhangi bir yere harcayabilir.
Sınırlayıcı şartlar, burada kilidin nasıl açılacağına dair daha fazla kısıtlama getirmek, örneğin UTXO sonrasındaki harcamaları sınırlamak gibi, yani "belirli amaçlar için ayrılmış fonlar" etkisini sağlamak; veya bir işlemdeki diğer girdi koşulları gibi daha fazla kısıtlama yapmaktır.
Daha titiz bir şekilde söylemek gerekirse, mevcut Bitcoin script'inin de belirli kısıtlamaları vardır. Örneğin, opcode tabanlı zaman kilidi, işlem harcaması öncesinde zaman kısıtlaması sağlamak için nLock veya nSequence alanlarını kullanarak gerçekleştirilir, ancak esasen sadece zamanla ilgili kısıtlamalarla sınırlıdır.
O halde, geliştiriciler ve araştırmacılar neden bu kısıtlama kontrollerini tasarlamak zorundalar? Çünkü kısıtlama maddeleri sadece kısıtlamak için değil, aynı zamanda işlem yürütme kurallarını belirlemek için vardır. Bu şekilde, kullanıcılar yalnızca önceden belirlenmiş kurallara uygun olarak işlem gerçekleştirebilir ve böylece planlanan iş akışını tamamlayabilirler.
Bu nedenle, daha fazla uygulama senaryosunu açığa çıkarabilir.
Uygulama Senaryoları
Staking cezalarının sağlanması
Kısıtlama koşullarının en gözle görülür örneklerinden biri, Babylon'un Bitcoin staking sürecindeki slash işlemi.
Babylon'un Bitcoin staking süreci, kullanıcıların kendi BTC varlıklarını ana zincir üzerinde özel bir script'e göndermesidir, harcama koşulları iki türü içerir:
Normal durumda: Belirli bir süre sonra, kullanıcı kendi imzası ile kilidi açabilir, yani unstake sürecini tamamlayabilir.
Anormal durumlar: Eğer kullanıcı, Babylon tarafından kiralanmış bir güvenlik PoS zincirinde çift imza gibi kötü niyetli davranışlar sergiliyorsa, o zaman EOTS( çıkarılabilir tek seferlik imzalar, bir kez kullanılabilir imzalar) aracılığıyla bu varlık kısmı kilidini açabilir ve ağdaki yürütme rollerinden biri, bir kısmını zorla yakım adresine( gönderir.
Buradaki "zorla gönderme" kavramına dikkat edin, bu, bu UTXO'yu çözmek mümkün olsa bile, varlığın rastgele başka bir yere gönderilemeyeceği, yalnızca yakılabileceği anlamına gelir. Böylece kötü niyetli kullanıcıların, bilinen imzalarını kullanarak varlıkları kendilerine geri gönderme girişiminde bulunarak cezadan kaçınmalarının önüne geçilmiş olur.
Bu özellik, OP_CTV gibi kısıtlama şartları uygulandıktan sonra, staking scriptinin "istisnai durum" dalında OP_CTV gibi opcode'ların eklenmesiyle kısıtlamaların uygulanmasını sağlayabilir.
Ancak OP_CTV etkinleştirilmeden önce, Babylon'un kullanıcı + komite tarafından birlikte yürütülen bir yöntemle kısıtlama şartlarının zorunlu uygulanmasının etkisini simüle etmesi gerekmektedir.
![Covenants Hakkında Detaylı Açıklama: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) Tıkanıklık Kontrolü
Genel olarak, tıkanıklık, Bitcoin ağı üzerindeki işlem ücretlerinin çok yüksek olduğu, işlem havuzunda paketlenmeyi bekleyen birçok işlemin biriktiği durumu ifade eder. Bu nedenle, kullanıcıların işlemlerini hızlı bir şekilde onaylatmak istemeleri durumunda, işlem ücretlerini artırmaları gerekir.
Bu durumda, bir kullanıcı birden fazla alıcıya birden fazla işlem göndermek zorunda kalırsa, işlem ücretlerini artırmak ve daha yüksek maliyetler üstlenmek zorunda kalacaktır. Bu da tüm ağın işlem ücretlerini daha da artıracaktır.
Eğer kısıtlama koşulları varsa, bir çözüm, gönderenin önce toplu bir işlem için taahhüt vermesi olabilir. Bu taahhüt, tüm alıcıların nihai işlemin gerçekleşeceğinden emin olmasını sağlar; böylece, işlem ücretlerinin düşük olduğu bir zamanı bekleyerek belirli işlemleri gönderebilirler.
Blok alanına olan talep yüksek olduğunda, işlem yapmak çok pahalı hale gelir. OP_CHECKTEMPLATEVERIFY kullanarak, büyük ölçekli ödeme işlemcileri tüm ödemelerini tek bir O###1( işlemi içinde birleştirerek onaylatabilirler. Daha sonra, bir süre sonra blok alanına olan talep azaldığında, ödemeler bu UTXO'dan genişletilebilir.
Bu sahne, OP_CTV sınırlama maddesinin önerdiği tipik bir uygulama örneğidir.
) Cüzdan
Kasa ###vault(, Bitcoin uygulamalarında yaygın olarak tartışılan bir uygulama senaryosudur, özellikle kısıtlama koşulları alanında. Günlük işlemlerde, fonların korunması ile fon kullanım ihtiyaçları arasında denge kurmak kaçınılmaz olduğundan, insanların güvenliği garanti eden bir tür kasa uygulaması olmasını istemektedir: Fonların güvenliğini sağlamak, hatta hesap hacklense bile ) özel anahtar ( sızdırılsa bile fonların kullanımını sınırlamak.
Gerçekleştirme sınırlama şartlarına dayalı olarak, cüzdan benzeri uygulamalar oldukça kolay bir şekilde inşa edilebilir.
OP_VAULT tasarım planı örneği olarak: bir güvenlik hazinesindeki fonları harcamak için önce zincire bir işlem göndermek gerekmektedir. Bu işlem, güvenlik hazinesini harcama niyetini "tetikleyici" olarak belirtir ve içinde şartlar belirler:
Her şey yolunda giderse, ikinci işlem nihai çekim işlemi olacaktır. N blok bekledikten sonra, fonlar herhangi bir yere harcanabilir.
Eğer bu işlem ) numaralı işlem çalındıysa veya "anahtar saldırısı" ile zorlandıysa, N blok sayısı kadar çekim işlemi gönderilmeden önce hemen başka bir güvenli adrese ( gönderebilirsiniz, böylece ) kullanıcı daha güvenli bir şekilde saklayabilir.
Dikkat edilmesi gereken nokta, sınırlayıcı şartlar olmadan bir cüzdan uygulaması oluşturulabileceğidir. Uygun bir yöntem, harcamalar için imzaları hazırlamak amacıyla özel anahtar kullanmak ve ardından bu özel anahtarı imha etmektir. Ancak hala birçok sınırlama bulunmaktadır, örneğin bu özel anahtarın ( gibi imha edildiğinden emin olunması, tutarsız bilgi kanıtlarındaki trusted setup sürecine benzer bir süreç ), miktar ve işlem ücretlerinin önceden belirlenmesi (, önceden imzalanması gereken ) nedeniyle esneklik eksikliği vb.
( Daha sağlam ve esnek durum kanalı
Genellikle, Lightning Network dahil olmak üzere durum kanallarının ana zincirle neredeyse eşit bir güvenliğe sahip olduğu kabul edilebilir ), düğümlerin en son durumu gözlemleyebilmesi ve en son durumu zincire normal bir şekilde yayınlayabilmesi durumunda ###. Ancak kısıtlayıcı şartlar getirildiğinde, bazı yeni durum kanalı tasarım fikirleri Lightning Network'ün üzerinde daha sağlam veya esnek hale gelebilir. Bunlar arasında en bilinenleri Eltoo, Ark vb. bulunmaktadır.
Eltoo (, LN-Symmetry) olarak da bilinen, bu konuda oldukça tipik bir örnektir. Bu teknik çözüm, "L2"nin homofonunu alarak, Lightning Network için bir yürütme katmanı önerir ve böylece herhangi bir sonraki kanal durumunun önceki durumu değiştirmesine izin verir, ceza mekanizmasına ihtiyaç duymadan, bu nedenle Lightning Network düğümleri gibi, rakiplerin kötü niyetli davranışlarını önlemek için birden fazla önceki durumu saklama zorunluluğunu da ortadan kaldırır. Yukarıdaki etkiyi gerçekleştirmek için, Eltoo SIGHASH_NOINPUT imza yöntemini önerdi, yani APO(BIP-118).
Ark, Lightning Network'ün giriş akışını ve kanal yönetimini azaltmayı hedeflemektedir. Bu, joinpool biçiminde bir protokoldür, birden fazla kullanıcı belirli bir süre boyunca bir hizmet sağlayıcısını karşı taraf olarak kabul edebilir, zincir dışı sanal UTXO(vUTXO) işlemleri gerçekleştirebilir, ancak maliyetleri azaltmak için zincir üzerinde bir UTXO paylaşabilir. Vault'a benzer şekilde, Ark mevcut Bitcoin ağı üzerinde de gerçekleştirilebilir; ancak sınırlayıcı hükümler getirildikten sonra, Ark, işlem şablonlarına dayanarak gerekli etkileşim miktarını azaltabilir ve daha az güvene dayalı tek taraflı çıkışları mümkün kılabilir.
Sınırlayıcı Şartlar Teknik Genel Bakış
Yukarıdaki uygulamalardan görülebileceği gibi, sınırlayıcı şartlar daha çok bir etki gibi görünmekte ve belirli bir teknoloji olmaktan ziyade birçok farklı teknik yöntemle uygulanabilir. Eğer sınıflandırma yapılırsa, aşağıdakileri içerebilir:
Tür: Genel, Özel
Uygulama Yöntemi: Opcode Tabanlı, İmza Tabanlı
Rekürsif: Rekürsif, rekürsif olmayan
Bunlar arasında, özyineleme şu anlama gelir: Bazı kısıtlama koşullarının uygulanması, bir sonraki çıktıyı kısıtlamak için de kullanılabilir ve bu da daha sonraki çıktıyı kısıtlayarak, eklenen kısıtlamaların bir işlemden daha fazlasını aşabilmesini ve daha yüksek bir işlem derinliğine ulaşabilmesini sağlar.
Bazı yaygın sınırlama maddesi tasarımları şunlardır:
OP_CTV: Genel tür, Opcode'a dayalı, özyinelemeli değil
OP_VAULT: Özel tip, Opcode'a dayalı, tekrarsız
APO: Genel tip, imzaya dayalı, özyinelemeli değil
OP_CAT: Genel tip, Opcode'a dayalı, özyinelemeli *
OP_CSFS: Genel tip, imza tabanlı, özyinelemeli
*OP_CAT ile birleştirilirse
Kısıtlama Şartlarının Tasarımı
Önceki tanıtımdan anlaşılacağı üzere, mevcut Bitcoin script'i esas olarak kilidin koşullarını sınırlamakta, bu UTXO'nun nasıl harcandığını ise sınırlamamaktadır. Kısıtlama maddelerini gerçekleştirmek için tersine düşünmemiz gerekiyor: Neden mevcut Bitcoin script'i kısıtlama maddelerini gerçekleştiremiyor?
Sebep, mevcut Bitcoin script'inin işlemin kendisinin içeriğini okuyamamasıdır, yani işlemin "iç gözlem" (introspection).
Eğer işlemlerin iç gözlemini gerçekleştirebilirsek - işlemle ilgili her şeyi kontrol etmek ( dahil olmak üzere çıktılar ), o zaman kısıtlama şartlarını gerçekleştirebiliriz.
Bu nedenle sınırlama şartlarının tasarım düşüncesi esas olarak öz değerlendirmeyi nasıl gerçekleştireceği etrafında dönmektedir.
( İşlem koduna dayalı vs İmza temelli
En basit ve doğrudan fikir, bir veya daha fazla işlem kodu ) eklemek, yani bir işlem kodu + birden fazla parametre veya farklı işlevlere sahip birden fazla işlem kodu ### ekleyerek, işlemin içeriğini doğrudan okumaktır. Bu da işlem kodlarına dayalı bir yaklaşımı ifade eder.
Diğer bir düşünce, script içinde işlem içeriğini doğrudan okumak ve kontrol etmek yerine, işlem içeriğinin hash'ini kullanmak olabilir - eğer bu hash zaten imzalanmışsa, o zaman script içinde OP_CHECKSIG gibi değişiklikler yaparak bu imzanın kontrolünü sağlamak, işlem içgörüsü ve kısıtlayıcı şartları dolaylı olarak gerçekleştirmek mümkündür. Bu düşünce, imza bazlı bir tasarım yaklaşımına dayanmaktadır. Ana olarak APO ve OP_CSFS gibi öğeleri içerir.
( APO
SIGHASH_ANYPREVOUT)APO###, önerilen bir Bitcoin imzalama yöntemidir. İmzanın en basit yolu, işlemin giriş ve çıkışlarına taahhüt etmektir, ancak Bitcoin'in daha esnek bir yolu vardır, yani SIGHASH, bir işlemdeki giriş veya çıkışlara seçici olarak taahhüt etmektir.
APO'nun SIGHASH'ı yalnızca çıktıyı imzalar, girdi kısmını imzalamaz. Bu da demektir ki, APO yöntemiyle imzalanmış bir işlem, şu şekilde devam edebilir:
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ıtlamalarının detayları: Programlanabilirlik çağının başlaması
Kısıtlama Maddelerinin Detayları: Bitcoin'in Programlanabilirliğini Gerçekleştirmek
Son dönemde Bitcoin topluluğu, OP_CAT gibi işlem kodlarının yeniden kullanılmasını tartışmaya açtı. Taproot Wizard, Quantum Cats NFT'yi piyasaya sürerek ve BIP-420 numarasını aldığını iddia ederek birçok kişinin dikkatini çekti. Destekçiler, OP_CAT'in etkinleştirilmesinin "kısıtlama şartları" sağladığını ve böylece Bitcoin'in akıllı sözleşmeler veya programlanabilirlik elde edebileceğini savunuyor.
Eğer "sınırlama şartları" terimini fark ederseniz ve biraz araştırma yaparsanız, bunun başka bir büyük tavşan deliği olduğunu göreceksiniz. Geliştiriciler, OP_CAT dışında OP_CTV, APO, OP_VAULT gibi sınırlama şartlarını uygulayan teknolojileri yıllardır tartışıyor.
Peki, Bitcoin'in "kısıtlama şartları" tam olarak nedir? Neden bu kadar çok geliştiricinin yıllarca süren dikkatini ve tartışmasını çekiyor? Bitcoin'in hangi programlanabilirliklerini gerçekleştirebilir? Arka plandaki tasarım prensipleri nasıldır? Bu makale, genel bir tanıtım ve tartışma yapmayı denemektedir.
"Sınırlayıcı Şartlar" nedir
Sınırlamalar (Taahhütler ), gelecekteki Bitcoin işlemlerine şartlar koyabilen bir mekanizmadır.
Mevcut Bitcoin script'i, harcama sırasında geçerli bir imza girmeyi, uygun bir script sağlamayı gerektiren kısıtlayıcı koşulları da içerir. Ancak kullanıcı kilidi açabildiği sürece, bu UTXO'yu istediği herhangi bir yere harcayabilir.
Sınırlayıcı şartlar, burada kilidin nasıl açılacağına dair daha fazla kısıtlama getirmek, örneğin UTXO sonrasındaki harcamaları sınırlamak gibi, yani "belirli amaçlar için ayrılmış fonlar" etkisini sağlamak; veya bir işlemdeki diğer girdi koşulları gibi daha fazla kısıtlama yapmaktır.
Daha titiz bir şekilde söylemek gerekirse, mevcut Bitcoin script'inin de belirli kısıtlamaları vardır. Örneğin, opcode tabanlı zaman kilidi, işlem harcaması öncesinde zaman kısıtlaması sağlamak için nLock veya nSequence alanlarını kullanarak gerçekleştirilir, ancak esasen sadece zamanla ilgili kısıtlamalarla sınırlıdır.
O halde, geliştiriciler ve araştırmacılar neden bu kısıtlama kontrollerini tasarlamak zorundalar? Çünkü kısıtlama maddeleri sadece kısıtlamak için değil, aynı zamanda işlem yürütme kurallarını belirlemek için vardır. Bu şekilde, kullanıcılar yalnızca önceden belirlenmiş kurallara uygun olarak işlem gerçekleştirebilir ve böylece planlanan iş akışını tamamlayabilirler.
Bu nedenle, daha fazla uygulama senaryosunu açığa çıkarabilir.
Uygulama Senaryoları
Staking cezalarının sağlanması
Kısıtlama koşullarının en gözle görülür örneklerinden biri, Babylon'un Bitcoin staking sürecindeki slash işlemi.
Babylon'un Bitcoin staking süreci, kullanıcıların kendi BTC varlıklarını ana zincir üzerinde özel bir script'e göndermesidir, harcama koşulları iki türü içerir:
Buradaki "zorla gönderme" kavramına dikkat edin, bu, bu UTXO'yu çözmek mümkün olsa bile, varlığın rastgele başka bir yere gönderilemeyeceği, yalnızca yakılabileceği anlamına gelir. Böylece kötü niyetli kullanıcıların, bilinen imzalarını kullanarak varlıkları kendilerine geri gönderme girişiminde bulunarak cezadan kaçınmalarının önüne geçilmiş olur.
Bu özellik, OP_CTV gibi kısıtlama şartları uygulandıktan sonra, staking scriptinin "istisnai durum" dalında OP_CTV gibi opcode'ların eklenmesiyle kısıtlamaların uygulanmasını sağlayabilir.
Ancak OP_CTV etkinleştirilmeden önce, Babylon'un kullanıcı + komite tarafından birlikte yürütülen bir yöntemle kısıtlama şartlarının zorunlu uygulanmasının etkisini simüle etmesi gerekmektedir.
![Covenants Hakkında Detaylı Açıklama: Bitcoin'in Programlanabilirliğini Nasıl Gerçekleştiririz?])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) Tıkanıklık Kontrolü
Genel olarak, tıkanıklık, Bitcoin ağı üzerindeki işlem ücretlerinin çok yüksek olduğu, işlem havuzunda paketlenmeyi bekleyen birçok işlemin biriktiği durumu ifade eder. Bu nedenle, kullanıcıların işlemlerini hızlı bir şekilde onaylatmak istemeleri durumunda, işlem ücretlerini artırmaları gerekir.
Bu durumda, bir kullanıcı birden fazla alıcıya birden fazla işlem göndermek zorunda kalırsa, işlem ücretlerini artırmak ve daha yüksek maliyetler üstlenmek zorunda kalacaktır. Bu da tüm ağın işlem ücretlerini daha da artıracaktır.
Eğer kısıtlama koşulları varsa, bir çözüm, gönderenin önce toplu bir işlem için taahhüt vermesi olabilir. Bu taahhüt, tüm alıcıların nihai işlemin gerçekleşeceğinden emin olmasını sağlar; böylece, işlem ücretlerinin düşük olduğu bir zamanı bekleyerek belirli işlemleri gönderebilirler.
Blok alanına olan talep yüksek olduğunda, işlem yapmak çok pahalı hale gelir. OP_CHECKTEMPLATEVERIFY kullanarak, büyük ölçekli ödeme işlemcileri tüm ödemelerini tek bir O###1( işlemi içinde birleştirerek onaylatabilirler. Daha sonra, bir süre sonra blok alanına olan talep azaldığında, ödemeler bu UTXO'dan genişletilebilir.
Bu sahne, OP_CTV sınırlama maddesinin önerdiği tipik bir uygulama örneğidir.
) Cüzdan
Kasa ###vault(, Bitcoin uygulamalarında yaygın olarak tartışılan bir uygulama senaryosudur, özellikle kısıtlama koşulları alanında. Günlük işlemlerde, fonların korunması ile fon kullanım ihtiyaçları arasında denge kurmak kaçınılmaz olduğundan, insanların güvenliği garanti eden bir tür kasa uygulaması olmasını istemektedir: Fonların güvenliğini sağlamak, hatta hesap hacklense bile ) özel anahtar ( sızdırılsa bile fonların kullanımını sınırlamak.
Gerçekleştirme sınırlama şartlarına dayalı olarak, cüzdan benzeri uygulamalar oldukça kolay bir şekilde inşa edilebilir.
OP_VAULT tasarım planı örneği olarak: bir güvenlik hazinesindeki fonları harcamak için önce zincire bir işlem göndermek gerekmektedir. Bu işlem, güvenlik hazinesini harcama niyetini "tetikleyici" olarak belirtir ve içinde şartlar belirler:
Dikkat edilmesi gereken nokta, sınırlayıcı şartlar olmadan bir cüzdan uygulaması oluşturulabileceğidir. Uygun bir yöntem, harcamalar için imzaları hazırlamak amacıyla özel anahtar kullanmak ve ardından bu özel anahtarı imha etmektir. Ancak hala birçok sınırlama bulunmaktadır, örneğin bu özel anahtarın ( gibi imha edildiğinden emin olunması, tutarsız bilgi kanıtlarındaki trusted setup sürecine benzer bir süreç ), miktar ve işlem ücretlerinin önceden belirlenmesi (, önceden imzalanması gereken ) nedeniyle esneklik eksikliği vb.
( Daha sağlam ve esnek durum kanalı
Genellikle, Lightning Network dahil olmak üzere durum kanallarının ana zincirle neredeyse eşit bir güvenliğe sahip olduğu kabul edilebilir ), düğümlerin en son durumu gözlemleyebilmesi ve en son durumu zincire normal bir şekilde yayınlayabilmesi durumunda ###. Ancak kısıtlayıcı şartlar getirildiğinde, bazı yeni durum kanalı tasarım fikirleri Lightning Network'ün üzerinde daha sağlam veya esnek hale gelebilir. Bunlar arasında en bilinenleri Eltoo, Ark vb. bulunmaktadır.
Eltoo (, LN-Symmetry) olarak da bilinen, bu konuda oldukça tipik bir örnektir. Bu teknik çözüm, "L2"nin homofonunu alarak, Lightning Network için bir yürütme katmanı önerir ve böylece herhangi bir sonraki kanal durumunun önceki durumu değiştirmesine izin verir, ceza mekanizmasına ihtiyaç duymadan, bu nedenle Lightning Network düğümleri gibi, rakiplerin kötü niyetli davranışlarını önlemek için birden fazla önceki durumu saklama zorunluluğunu da ortadan kaldırır. Yukarıdaki etkiyi gerçekleştirmek için, Eltoo SIGHASH_NOINPUT imza yöntemini önerdi, yani APO(BIP-118).
Ark, Lightning Network'ün giriş akışını ve kanal yönetimini azaltmayı hedeflemektedir. Bu, joinpool biçiminde bir protokoldür, birden fazla kullanıcı belirli bir süre boyunca bir hizmet sağlayıcısını karşı taraf olarak kabul edebilir, zincir dışı sanal UTXO(vUTXO) işlemleri gerçekleştirebilir, ancak maliyetleri azaltmak için zincir üzerinde bir UTXO paylaşabilir. Vault'a benzer şekilde, Ark mevcut Bitcoin ağı üzerinde de gerçekleştirilebilir; ancak sınırlayıcı hükümler getirildikten sonra, Ark, işlem şablonlarına dayanarak gerekli etkileşim miktarını azaltabilir ve daha az güvene dayalı tek taraflı çıkışları mümkün kılabilir.
Sınırlayıcı Şartlar Teknik Genel Bakış
Yukarıdaki uygulamalardan görülebileceği gibi, sınırlayıcı şartlar daha çok bir etki gibi görünmekte ve belirli bir teknoloji olmaktan ziyade birçok farklı teknik yöntemle uygulanabilir. Eğer sınıflandırma yapılırsa, aşağıdakileri içerebilir:
Bunlar arasında, özyineleme şu anlama gelir: Bazı kısıtlama koşullarının uygulanması, bir sonraki çıktıyı kısıtlamak için de kullanılabilir ve bu da daha sonraki çıktıyı kısıtlayarak, eklenen kısıtlamaların bir işlemden daha fazlasını aşabilmesini ve daha yüksek bir işlem derinliğine ulaşabilmesini sağlar.
Bazı yaygın sınırlama maddesi tasarımları şunlardır:
*OP_CAT ile birleştirilirse
Kısıtlama Şartlarının Tasarımı
Önceki tanıtımdan anlaşılacağı üzere, mevcut Bitcoin script'i esas olarak kilidin koşullarını sınırlamakta, bu UTXO'nun nasıl harcandığını ise sınırlamamaktadır. Kısıtlama maddelerini gerçekleştirmek için tersine düşünmemiz gerekiyor: Neden mevcut Bitcoin script'i kısıtlama maddelerini gerçekleştiremiyor?
Sebep, mevcut Bitcoin script'inin işlemin kendisinin içeriğini okuyamamasıdır, yani işlemin "iç gözlem" (introspection).
Eğer işlemlerin iç gözlemini gerçekleştirebilirsek - işlemle ilgili her şeyi kontrol etmek ( dahil olmak üzere çıktılar ), o zaman kısıtlama şartlarını gerçekleştirebiliriz.
Bu nedenle sınırlama şartlarının tasarım düşüncesi esas olarak öz değerlendirmeyi nasıl gerçekleştireceği etrafında dönmektedir.
( İşlem koduna dayalı vs İmza temelli
En basit ve doğrudan fikir, bir veya daha fazla işlem kodu ) eklemek, yani bir işlem kodu + birden fazla parametre veya farklı işlevlere sahip birden fazla işlem kodu ### ekleyerek, işlemin içeriğini doğrudan okumaktır. Bu da işlem kodlarına dayalı bir yaklaşımı ifade eder.
Diğer bir düşünce, script içinde işlem içeriğini doğrudan okumak ve kontrol etmek yerine, işlem içeriğinin hash'ini kullanmak olabilir - eğer bu hash zaten imzalanmışsa, o zaman script içinde OP_CHECKSIG gibi değişiklikler yaparak bu imzanın kontrolünü sağlamak, işlem içgörüsü ve kısıtlayıcı şartları dolaylı olarak gerçekleştirmek mümkündür. Bu düşünce, imza bazlı bir tasarım yaklaşımına dayanmaktadır. Ana olarak APO ve OP_CSFS gibi öğeleri içerir.
( APO
SIGHASH_ANYPREVOUT)APO###, önerilen bir Bitcoin imzalama yöntemidir. İmzanın en basit yolu, işlemin giriş ve çıkışlarına taahhüt etmektir, ancak Bitcoin'in daha esnek bir yolu vardır, yani SIGHASH, bir işlemdeki giriş veya çıkışlara seçici olarak taahhüt etmektir.
APO'nun SIGHASH'ı yalnızca çıktıyı imzalar, girdi kısmını imzalamaz. Bu da demektir ki, APO yöntemiyle imzalanmış bir işlem, şu şekilde devam edebilir: