Bitcoin Script Dili Nedir?

Bitcoin Script, Bitcoin ağındaki her işlemi kontrol eden programlama dilidir. Bu, Bitcoin’in hangi koşullarda harcanabileceğini kesin olarak tanımlayan, basit ve yığın tabanlı bir dildir; ağdaki her tam düğüm, bir işlem doğrulandığında bu dili çalıştırır. Bu dil olmasaydı, Bitcoin, kimin neye sahip olduğunu belirleyecek bir mekanizma içermeyen, sadece sayılardan oluşan bir defter olurdu.

Çoğu kullanıcı, Bitcoin komut dosyası dilini hiçbir zaman doğrudan görmez. Cüzdanları bu işlemi görünmez bir şekilde halleder. Ancak her BTC gönderdiğinizde veya aldığınızda, binlerce bilgisayarda aynı anda iki küçük program çalışır ve harcama koşullarının karşılanıp karşılanmadığını kontrol eder. Bunun nasıl işlediğini anlamak, Bitcoin'in neden bu şekilde yapılandırıldığını ve Ethereum gibi platformlarla karşılaştırıldığında neler yapabileceğini ve yapamayacağını büyük ölçüde açıklar.

Bu makale, Bitcoin Script’in nasıl çalıştığını ele alıyor, bu sistemin mümkün kıldığı başlıca işlem türlerini ayrıntılı olarak inceliyor, 2021 yılında komut dosyası katmanını modernize eden Taproot güncellemesini açıklıyor ve Haziran 2026 itibarıyla covenant opcode tartışmasının geldiği noktayı ele alıyor.

Kendi kontrolünüz altındaki cüzdan ile Bitcoin’lerinizi güvenli bir şekilde yönetin Bitcoin.com Cüzdan uygulaması.

Önemli Noktalar

• Bitcoin Script, Bitcoin protokolüne entegre edilmiş, herhangi bir Bitcoin çıkışının hangi koşullar altında harcanabileceğini tanımlayan yığın tabanlı bir programlama dilidir.
• Her Bitcoin işlemi iki komut dosyası içerir: alıcı tarafından belirlenen bir kilitleme komut dosyası (ScriptPubKey) ve harcama yapan tarafça sağlanan bir kilit açma komut dosyası (ScriptSig). Bir işlemin geçerli olabilmesi için her ikisinin de başarıyla yürütülmesi gerekir.
• Bitcoin Script, kasıtlı olarak Turing tam değildir. Döngü içermez, yürütmeler arasında kalıcı bir durum barındırmaz ve komut dosyası boyutunda katı sınırlamalar vardır. Bu sayede her komut dosyasının sonlanacağı garanti edilir; bu bir sınırlama değil, bir güvenlik özelliğidir.
• Komut dosyası dili, P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) ve Taproot (P2TR) olmak üzere beş ana format üzerinden gelişmiştir; her biri geriye dönük uyumluluğu korurken olanakları genişletmiştir.
• Taproot (Kasım 2021) güncellemesiyle Schnorr imzaları, gizlilik için MAST tabanlı harcama yolları ve gelecekteki güncellemelerin daha sorunsuz gerçekleşmesini sağlayan yerleşik bir mekanizmaya sahip, güncellenmiş bir komut dosyası dili olan Tapscript tanıtıldı.
• Bitcoin Script üzerine kurulu gerçek hayattaki kullanım örnekleri arasında çoklu imza cüzdanları, zaman kilitli işlemler, Hash Time-Locked Contracts (Lightning’in temeli), emanet hizmetleri ve Discreet Log Contracts yer almaktadır.
• Ethereum akıllı sözleşmelerinden farklı olarak, Bitcoin Script durum bilgisi içermez: her bir komut dosyası, diğer işlemler hakkında hiçbir bilgiye sahip olmadan tamamen izole bir şekilde çalışır. Bu, kasıtlı olarak yapılan bir mimari tercihtir.
• 2026 yılında Bitcoin Script geliştirme alanında en aktif olan konu, sözleşme opkodlarıdır; özellikle OP_CTV (BIP-119) ve OP_CAT (BIP-347), bu opkodlar sayesinde script’lerin harcama işlemlerinin nasıl olması gerektiğini belirlemesi mümkün olacaktır. Her ikisi de henüz ana ağda etkinleştirilmemiştir.

Bitcoin Script Nedir?

Bitcoin Script, Bitcoin protokolüne entegre edilmiş, yığın tabanlı ve durum bilgisi içermeyen bir komut dosyası dilidir. Bitcoin ağındaki her işlem çıktısı, fonların harcanması için gerekli koşulları belirleyen bir kilitleme komut dosyası (ScriptPubKey olarak adlandırılır) içerir. Bu fonları harcamak isteyen herkes, söz konusu koşulları karşılayan bir kilit açma komut dosyası (ScriptSig olarak adlandırılır; SegWit ve Taproot işlemlerinde ise tanık verisi olarak adlandırılır) sunmalıdır.

Bu dil, yapısını 1960’larda geliştirilen minimalist, yığın tabanlı bir programlama dili olan Forth’tan almaktadır. Forth gibi, Bitcoin Script de soldan sağa okunur, yığın adı verilen bir veri yapısı üzerinde çalışır ve operatörlerin işlenenlerin önüne değil arkasına geldiği Ters Polonyalı Notasyon (RPN) kullanır. Her seferinde tek bir komut yürütür, döngü içermez ve yürütmeler arasında kalıcı bellek taşımaz.

Bu son nokta, Bitcoin Script’i protokol düzeyinde incelerken çoğu kişinin ilk olarak karşılaştığı husustur: Bu dil, kasıtlı olarak Turing tam değildir. Turing tam bir dil, yeterli zaman ve kaynak sağlandığında her türlü hesaplamayı gerçekleştirebilir. Bitcoin Script ise tasarım gereği bunu yapamaz ve bu seçimin ardındaki nedenler, ağın işleyişi açısından büyük önem taşır.

Bitcoin Script Nasıl Çalışır: Yığın Modeli

Bitcoin Script’in nasıl çalıştığını anlamak için yığını anlamanız gerekir. Yığın, Son Giren İlk Çıkar (LIFO) ilkesine göre işleyen bir veri yapısıdır. Bir tabak yığını düşünün: sadece en üstten ekleme veya çıkarma yapabilirsiniz. Bitcoin Script'te veriler yığına itilir ve opkodlar (işlem kodları) yığının en üstünde bulunan öğeyi işler.

Bir Bitcoin düğümü bir işlemi doğruladığında, sırayla iki komut dosyası çalıştırır:

1. Kilidi açma komut dosyası (ScriptSig veya tanık) paraları harcayan kişi tarafından sağlanır. Bu işlem, genellikle bir dijital imza ve bir açık anahtardan oluşan verileri yığına ekler.
2. Kilitleme komut dosyası (ScriptPubKey) harcanacak çıktıya bağlıdır. Bu, yığın verileri üzerinde işlem yapan ve harcama koşullarının karşılanıp karşılanmadığını doğrulayan opkodları içerir.

Komut dosyası hatasız bir şekilde çalışır ve sonunda yığın üzerinde sıfırdan farklı bir değer (TRUE) bırakırsa, işlem geçerlidir. Hata verirse veya FALSE bırakırsa, işlem düğüm tarafından reddedilir ve hiçbir zaman bir bloğa dahil edilmez.

Bu işlem tamamen durum bilgisi içermez. Komut dosyası, önceki işlemler hakkında hiçbir bilgiye sahip değildir, mevcut bakiyelerden haberdar değildir ve komut dosyasının çalışması sona erdikten sonra devredilen herhangi bir bellek bilgisi de yoktur. Her komut dosyası her seferinde sıfırdan ve izole bir şekilde çalışır.

Adım Adım: Standart Bir P2PKH İşlemi

Pay-to-Public-Key-Hash (P2PKH), 2009 yılından beri kullanılan orijinal Bitcoin işlem türüdür. P2PKH adresleri "1." ile başlar. ScriptPubKey ve ScriptSig’in pratikte nasıl göründüğü aşağıda gösterilmiştir:

Şifre çözme komut dosyası (ScriptSig):

<imza> <açık anahtar>

Kilitleme komut dosyası (ScriptPubKey):

OP_DUP OP_HASH160 <açık anahtar hash'i> OP_EQUALVERIFY OP_CHECKSIG

Düğüm her ikisini de birleştirip birlikte çalıştırdığında, yığın işlemleri adım adım ilerler:

• ScriptSig’den alınan imza ve açık anahtar yığına eklenir
• OP_DUP yığının en üstündeki açık anahtarı kopyalar
• OP_HASH160 yinelenen verinin hash değerini hesaplar (SHA-256 ve ardından RIPEMD-160), böylece 20 baytlık bir hash değeri üretir
• Kilitleme betiğinden gelen açık anahtar hash değeri yığına eklenir
• OP_EQUALVERIFY iki hash değerinin eşleşip eşleşmediğini kontrol eder. Eşleşmezlerse, işlem durdurulur ve işlem başarısız olur.
• OP_CHECKSIG imzanın açık anahtar için geçerli olup olmadığını doğrular

Tüm adımlar başarıyla tamamlanırsa, yığın TRUE değeriyle sona erer ve fonlar serbest bırakılır. Tüm süreç milisaniyeler sürer ve ağdaki her düğümde aynı şekilde çalışır.

Bitcoin Opkodları Açıklaması

Bitcoin opkodları, bir komut dosyasını oluşturan tek tek komutlardır. Her biri tek bir bayttır ve bu da 256 olası opkod yuvası anlamına gelir. Bunların yaklaşık 80’i şu anda ana ağda aktiftir. Geri kalanlar ise ya ayrılmış, devre dışı bırakılmış ya da Tapscript ile birlikte getirilen OP_SUCCESS ileriye dönük uyumluluk mekanizmasına atanmıştır.

Opkodlar birkaç kategoriye ayrılır:

• Veri aktarım opkodları açık anahtarlar, imzalar ve hash değerleri gibi değerleri yığına eklemek
• Aritmetik opkodları toplama, çıkarma ve karşılaştırma işlemleri yapabilir. Önemli bir nokta olarak, çarpma ve bölme işlemleri devre dışıdır.
• Kriptografik opkodlar karma hesaplaması için OP_SHA256, OP_HASH160 ve OP_SHA1; imza doğrulama için ise OP_CHECKSIG’i içerir
• Akış kontrol opkodları koşullu mantığı etkinleştir: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Yığın işleme opkodları OP_DUP (en üstteki öğeyi kopyalama), OP_DROP (en üstteki öğeyi kaldırma) ve OP_SWAP (en üstteki iki öğeyi yer değiştirme) gibi komutlar

2010 yılında, orijinal uygulamalarında güvenlik açıkları tespit edildikten sonra Satoshi Nakamoto tarafından birkaç opkod devre dışı bırakıldı. Bunlar arasında OP_CAT (iki yığın öğesini birleştirme), OP_MUL (çarpma) ve OP_DIV (bölme) yer almaktadır. Bu opkodların olmaması, Bitcoin Script'in ifade edebileceği şeyler üzerinde kalıcı sonuçlar doğurmuştur ve 2026 yılında en aktif şekilde tartışılan Bitcoin yükseltme önerilerinden birçoğu, bu opkodlardan bazılarının yeniden etkinleştirilip etkinleştirilmeyeceği konusunu ele almaktadır.

Onaltılık değerler ve açıklamaları içeren eksiksiz opkod referansı için, Bitcoin Wiki Komut Dosyası sayfası en güvenilir kaynaktır.

Turing Tamamlı Olmama Neden Bir Özelliktir?

Genel kabul gören açıklama şudur: Bitcoin Script’te döngü bulunmadığından, komut dosyalarının mutlaka sona ereceği garanti edilir ve bu sayede ağ, sonsuz yürütme durumundan korunur. Bu doğru olmakla birlikte, konunun özünü tam olarak yansıtmamaktadır.

Asıl mesele saldırı yüzeyiyle ilgilidir. Turing tam bir dil, herhangi bir hesaplamayı ifade edebilir. Bu ifade gücü aynı zamanda hataların barındığı alandır. Ethereum’un Solidity dili, tarihin en pahalıya mal olan yazılım güvenlik açıklarından bazılarına yol açmıştır. 2016'daki DAO saldırısı, bir akıllı sözleşmedeki yeniden giriş kusurundan yararlanarak o dönemki fiyatlarla yaklaşık 60 milyon dolarlık zarara yol açmış ve sonuçta Ethereum ağında tartışmalı bir hard fork'a neden olmuştur. Daha geniş DeFi ekosisteminde ise yıllar boyunca akıllı sözleşme istismarları yoluyla yüz milyonlarca dolarlık kayıp yaşanmıştır.

Bitcoin Script, bu tür saldırıları yapısal olarak imkânsız hale getirir. Başka komut dosyalarını çağıran, bir koşul değişene kadar döngüye giren veya işlemler arasında durum bilgisi depolayan bir Bitcoin komut dosyası yazamazsınız. Her script, sınırlı, sonlanabilir ve incelenebilir bir programdır. Maksimum script boyutu 10.000 bayttır. Script başına "push" olmayan opkodların maksimum sayısı 201'dir. Bir doğrulayıcı, script'i çalıştırmadan önce her zaman en kötü durumdaki yürütme maliyetini hesaplayabilir.

Yüzlerce milyar dolarlık değere sahip bir ağ için bu öngörülebilirlik, vazgeçtiğiniz esneklikten daha değerlidir. Ethereum, sınırsız hesaplama sorununu gaz limitleriyle çözer; kullanıcılardan yürütülen her opkod için ücret alır ve bütçesi tükenen komut dosyalarını durdurur. Bu yöntem işe yarar, ancak kendi karmaşıklığını ve arıza modlarını da beraberinde getirir. Bitcoin ise tasarım gereği bu sorunu tamamen ortadan kaldırır.

Bununla birlikte, “Turing tamlığı olmaması” “karmaşık mantık yürütememek” anlamına gelmez. Bitcoin Script, çok taraflı harcama gerekliliklerini, zamana dayalı koşulları, hash öngörüntü ortaya çıkarmayı ve bunların tümünün kombinasyonlarını destekler. Günde milyonlarca ödemeyi yönlendiren Lightning Ağı, tamamen Bitcoin Script temel öğeleri üzerine inşa edilmiştir.

Script Türleri: P2PKH’den Taproot’a Evrim

Bitcoin'in komut dosyası katmanı 2009'dan bu yana önemli ölçüde gelişmiştir; her güncellemede yeni bir işlem biçimi getirilmiş, ancak önceki tüm sürümlerle geriye dönük uyumluluk korunmuştur.

P2PK (Pay-to-Public-Key, 2009)

Satoshi'nin 170. blokta Hal Finney'e yaptığı ödeme de dahil olmak üzere ilk Bitcoin işlemlerinde kullanılan orijinal format. Fonlar, hash değeri yerine doğrudan tam bir açık anahtara kilitleniyordu. Günümüzde yeni işlemlerde nadiren kullanılmaktadır, çünkü harcama yapılmadan önce açık anahtarı zincir üzerinde ifşa eder; bu durum, anahtarı önceden hash işlemine tabi tutmaya kıyasla daha zayıf bir güvenlik önlemi olarak kabul edilir.

P2PKH (Pay-to-Public-Key-Hash, 2009)

On yılı aşkın süredir kullanılan standart format. P2PKH, fonları anahtarın kendisi yerine açık anahtarın bir hash değerine kilitler; böylece açık anahtar, harcama anına kadar gizli kalır, 20 baytlık daha kısa bir adres oluşturulur ve “1” ile başlayan tüm adreslerin temelini oluşturur. Unchained’in zincir içi verilerine göre (Nisan 2026), P2PKH adresleri şu anda madenciliği yapılmış bitcoin arzının yaklaşık %43’ünü elinde bulundurmaktadır.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

1 Nisan 2012 tarihinde bir soft fork yoluyla uygulamaya konulan P2SH, karmaşık harcama komut dosyalarının yükünü gönderen kişiden alıcıya kaydırdı. P2SH, çıktıya tam bir kilitleme komut dosyası eklemek yerine, bir “kullanım komut dosyası”nın 20 baytlık bir hash değerini çıktı olarak verir. Tam komut dosyası, ancak coinler harcandığında ortaya çıkar. Bu, çoklu imza (multisig) sistemini sıradan kullanıcılar için pratik hale getirdi: 2'den 3'lü çoklu imza kurulumunda, ödeme anında üç açık anahtarın da gönderen tarafından görülmesi artık gerekli değildi. P2SH adresleri "3" ile başlar.

P2SH doğrulamasının protokol düzeyinde nasıl işlediğine dair ayrıntılı bir açıklamaya ulaşmak için, developer.bitcoin.org'un işlem kılavuzu Redeem Script mekanizmasını adım adım ele alır.

P2WPKH ve P2WSH (Yerel SegWit, 2017, BIP 141)

2017 yılının Ağustos ayında 481.824. blokta etkinleştirilen Segregated Witness (SegWit), imza verilerini ana işlem gövdesinin dışına, ayrı bir tanık yapısına taşıdı. Tanık verileri %75’lik bir ağırlık indirimi aldığından, SegWit işlemleri önemli ölçüde daha ucuz hale geldi. Bir kaynağa ve iki çıktıya sahip standart bir P2WPKH işleminin ağırlığı yaklaşık 141 sanal bayt iken, eşdeğer bir P2PKH işleminin ağırlığı 226 vbyte’dir. Spark'ın Bitcoin adres türleri analizi Mart 2026'dan itibaren. SegWit ayrıca, Lightning Network için bir ön koşul olan işlem değiştirilebilirliği sorununu da çözdü. Yerel SegWit adresleri "bc1q" ile başlar.

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot, Kasım 2021’de 709.632. blokta devreye girmiştir ve SegWit’ten bu yana Bitcoin’in komut dosyası katmanına yapılan en önemli güncellemedir. Bu güncellemeyle Schnorr imzaları, MAST desteğine sahip yeni bir çıktı türü ve güncellenmiş bir komut dosyası dili olan Tapscript getirilmiştir. Taproot adresleri "bc1p" ile başlar.

Taproot ve Tapscript: Bitcoin Komut Dosyası Dili 2021’de Nasıl Değişti?

Taproot tek bir değişiklik değildir. Birlikte tasarlanmış ve eşzamanlı olarak devreye alınmış üç Bitcoin İyileştirme Önerisidir.

BIP 340: Schnorr İmzaları

Bitcoin başlangıçta ECDSA’yı (Eliptik Eğri Dijital İmza Algoritması) kullanıyordu. Satoshi, bu algoritmayı seçmesinin nedenlerinden biri, o dönemde Schnorr imzalarının patent koruması altında olmasıydı. Bu patentin süresi 2008’de doldu ve Taproot sayesinde Schnorr imzaları nihayet protokole entegre edildi.

Schnorr imzaları, ECDSA’nın 71-73 baytlık boyutuna kıyasla 64 bayt ile daha küçüktür. Daha da önemlisi, MuSig2 adlı bir şema aracılığıyla anahtar birleştirmeyi desteklerler. Anahtar birleştirme, birden fazla imzalayanın bireysel anahtarlarını ve imzalarını, zincir üzerinde sıradan bir tek imzalı ödemeden ayırt edilemeyen tek bir toplu anahtar ve imzaya birleştirmesine olanak tanır. Taproot'un işbirliğine dayalı anahtar yolu üzerinden harcama yapan 2'den 3'lü çoklu imza cüzdanı, blok zincirindeki standart bir ödemeyle aynı görünür. Bu, karmaşık bir saklama düzenlemesi kapsamında bitcoin sahibi olan herkes için gerçek bir gizlilik kazancıdır.

BIP 341: Pay-to-Taproot ve MAST

P2TR, iki harcama yolu içeren yeni bir çıktı türü sunuyor:

• A anahtar yolu Tüm tarafların mutabık kalması ve en basit, en ucuz yolu tercih etmesi durumunda kullanılan Schnorr imzası ile harcama yapmak
• A komut dosyası yolu MAST (Merkelize Edilmiş Soyut Sözdizimi Ağacı; bu kavramın Taproot uygulamasını ifade eder) kullanarak harcama yapmak

MAST, tek bir çıktının bir Merkle kökü aracılığıyla birden fazla harcama senaryosundan oluşan bir ağaca bağlanmasına olanak tanır. Harcama yapıldığında, zincir üzerinde yalnızca fiilen kullanılan belirli koşul ortaya çıkar. Ağaçtaki diğer tüm olası harcama yolları kalıcı olarak gizli kalır. "Normal şekilde harcama yapabilirim, ya da üç vekilden ikisi altı ay sonra harcama yapabilir, ya da bir kurtarma anahtarı iki yıl sonra harcama yapabilir" gibi karmaşık bir harcama politikası yapılandırmış bir kullanıcı için, yalnızca fiilen yürütülen yol blok zincirinde görünür.

Spark’ın Mart 2026’da aktardığı Glassnode verilerine göre, 2024 itibarıyla Taproot’un Bitcoin işlemlerindeki payı, büyük ölçüde Ordinals ve BRC-20 kayıt faaliyetlerinin etkisiyle yaklaşık %42’ye yükselmişti. O zamandan beri bu pay piyasa koşullarına bağlı olarak dalgalanmalar göstermiş olsa da, altyapı artık başlıca cüzdanlar ve borsalarda standart hale gelmiştir. Bitcoin Optech’in Taproot konu sayfası Taproot ile ilgili devam eden protokol geliştirme çalışmalarını takip eder.

BIP 342: Tapscript

Tapscript, Taproot içindeki script-path harcamaları için kullanılan güncellenmiş komut dosyası dilidir. Eski Bitcoin Script ile opkodların çoğunu paylaşır, ancak birkaç önemli değişiklik içerir:

• OP_CHECKMULTISIG ve OP_CHECKMULTISIGVERIFY artık kullanılmamaktadır. Eski multisig opkodunda, geçici bir çözüm olarak yığına sahte bir elemanın eklenmesini gerektiren bir tuhaflık vardı. Tapscript bunu ortadan kaldırır ve yerine şunu koyar: OP_CHECKSIGADD, bu da Schnorr imzalarını tek tek doğrular ve bir sayım tutar. Eşik çoklu imza şemalarının uygulanması daha basit ve daha ucuz hale gelir.
• MAST yaprağı başına komut dosyası boyut sınırlamaları kaldırılmıştır. Bir Taproot dalı içindeki tek tek komut dosyaları istenilen büyüklükte olabilir.
• OP_SUCCESS opkodları en ileriye dönük değişikliklerdir. Eski Script’te, tanımlanmamış bir opkodla karşılaşılması komut dosyasının başarısız olmasına neden olur. Tapscript’te ise OP_SUCCESS aralığındaki opkodlar, komut dosyasının koşulsuz olarak başarılı olmasını sağlar. Gelecekteki yazılım çatalları, yeni bir script sürümü veya ekosistem genelinde tam bir yeniden dağıtım döngüsü gerektirmeden, bu opkodların ne zaman başarılı olacağına dair kısıtlamalar ekleyerek onlara gerçek davranışlar atayabilir. Bitcoin'in script katmanına, protokol tarihindeki herhangi bir dönemden daha temiz bir şekilde yeni yetenekler eklenebilir.

Miniscript

Tapscript’in yanı sıra, Miniscript adlı ilgili bir proje de geliştiriciler için giderek daha fazla önem kazanmaktadır. Miniscript, Bitcoin Script’in analiz edilebilir, birleştirilebilir ve genel olarak imzalanabilir bir alt kümesini yazmanın yapılandırılmış bir yoludur. Ham Script'in manuel olarak oluşturulması gerekmesi ve denetlenmesi zor olması nedeniyle, Miniscript komut dosyalarının doğruluğu otomatik olarak doğrulanabilir ve daha büyük politikalara birleştirilebilir. Bu, Script'in yapabileceklerini genişletmez, ancak halihazırda yaptıklarını cüzdan ve saklama araçları geliştiren geliştiriciler için önemli ölçüde daha erişilebilir hale getirir.

Bitcoin Script’in Sağladığı Olanaklar: Gerçek Hayattaki Kullanım Örnekleri

Bugün Bitcoin ana ağında, tamamı Bitcoin Script temel öğeleri üzerine inşa edilmiş aşağıdaki işlem türleri aktiftir:

Çoklu imza (multisig) cüzdanları Bir harcama işlemini onaylamak için M-of-N özel anahtar gerektirir. Bir şirketin hazine departmanı, herhangi bir para çekme işlemi için 5'in 3'ünün onayını gerektirebilir. Evli bir çift, ortak tasarruf hesapları için 2'nin 2'sini kullanabilir. Taproot ve Schnorr anahtar birleştirme sayesinde, işbirliğine dayalı çoklu imza harcamaları artık zincir üzerinde standart tek imza işlemlerinden ayırt edilemez hale gelmiştir.

Zaman kilitli işlemler Belirli bir blok yüksekliğine veya geçen süreye ulaşılmadan önce fonların aktarılmasını önlemek için OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify veya CLTV) ve OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify veya CSV) kullanın. Uygulama alanları arasında miras planlaması, çalışanlara ait token hak kazanma takvimleri, zorunlu tasarruf mekanizmaları ve Lightning Network kanalları içinde kullanılan ceza işlemleri yer alır.

Hash Zaman Kilitli Sözleşmeler (HTLC’ler) bir hash öngörüme şartını bir zaman kilidi ile birleştirir. Harcama koşulu şu şekilde işler: Bu blok yüksekliğinden önce bu hash’in öngörüme değeri açıklanırsa, aksi takdirde fonlar gönderene geri döner. HTLC’ler, Lightning Network’ün temel bileşenidir ve aralarında doğrudan bir ilişki bulunmayan taraflar arasında kanal zincirleri üzerinden güvene dayalı olmayan ödeme yönlendirmesini mümkün kılar.

Emanet Bu düzenlemeler, fonları bir P2SH veya Taproot komut dosyasında kilitler; fonların serbest bırakılması için birden fazla tarafın mutabakatı gerekir ve genellikle bir üçüncü taraf hakem, eşitlik bozucu anahtara sahiptir.

Gizli Günlük Sözleşmeleri (DLC'ler) Oracle tabanlı Schnorr adaptör imzalarını kullanarak, fiyat akışları veya olay sonuçları gibi gerçek dünya verileriyle hesaplanan finansal sözleşmelerin, oracle’ın herhangi bir fonun saklayıcılığını üstlenmesine gerek kalmadan gerçekleştirilmesini sağlar. DLC’ler Bitcoin ana ağında aktif durumdadır ve Bitcoin ile hesaplanan opsiyon ve vadeli işlem ürünleri için kullanılmaktadır.

Bitcoin Script ve Ethereum Akıllı Sözleşmeleri Karşılaştırması

Hem Bitcoin Script hem de Ethereum’un Solidity’si, fonların hareket edebileceği koşulları tanımlar; ancak bunlar temelde farklı mimari tercihleri temsil eder. Bu karşılaştırmayı doğrudan yapmak önemlidir, çünkü aradaki farklar, her bir ağın kabul ettiği ödünleşimleri büyük ölçüde açıklamaktadır.

Temel ayrım noktası, durum bilgisi (statefulness) kavramıdır. Ethereum sözleşmeleri, işlemler arasında kalıcı olan verileri depolar ve değiştirir; bu da kredi protokollerini, merkeziyetsiz borsaları, zincir içi yönetişimi ve token standartlarını mümkün kılar. Bitcoin Script’te buna eşdeğer bir özellik yoktur. Her bir script, diğer işlemlerden habersiz bir şekilde, kendi içinde çalışır.

Bu, doldurulmayı bekleyen bir boşluk değil, kasıtlı bir mimari tercihtir. Bitcoin’in komut dosyası katmanı, tek bir belirli görev için tasarlanmıştır: Bitcoin harcamaya ilişkin koşulları, öngörülebilir ve güvenli bir şekilde, büyük ölçekte uygulamak. Bu görev için durum bilgisi olmama durumu bir avantajdır. Saldırı yüzeyi daha küçüktür, yürütme milyonlarca bağımsız doğrulayıcı arasında deterministiktir ve protokol düzeyinde durum bilgisi içeren sözleşmeler bulunmadığından, protokol düzeyinde akıllı sözleşme istismarı kategorisi de yoktur.

Bitcoin üzerine daha fazla programlanabilirlik eklemek isteyen projeler, bunu katmanlar halinde oluşturur. Lightning Network ödemeleri yönetir. DLC protokolleri ise harici verilere dayalı finansal sözleşmeleri yönetir. Ark ve Liquid Network gibi Katman-2 sistemleri, farklı ölçeklenebilirlik profillerine yönelik çözümler sunar. Bunların hiçbiri, temel katmanın komut dosyası modelinde değişiklik yapılmasını gerektirmez.

Sözleşme Tartışması: Bitcoin Script’te Neler Değişebilir?

Bitcoin Script'in gelişimi her zaman yavaş ve ihtiyatlı bir seyir izlemiştir. Şu anda en aktif geliştirme alanı, “covenant” opkodlarıdır; bunlar, bir script’in sadece bir çıktıyı kimin harcayabileceğini değil, ortaya çıkan işlemin nasıl olması gerektiğini de kısıtlamasına olanak tanıyacak önerilerdir. Bu, Script’in ifade gücünün anlamlı bir genişlemesidir.

Haziran 2026 itibarıyla öne çıkan öneriler şunlardır:

• OP_CTV (BIP-119, CheckTemplateVerify)Jeremy Rubin tarafından hazırlanan bu teklif, bir UTXO’yu işlemin sürümü, kilitlenme süresi, giriş sayısı, diziler, çıkış sayısı ve çıkışları içeren belirli, önceden belirlenmiş bir harcama şablonuna bağlayan tek bir opkod eklemektedir. Tasarım gereği özyinelemesiz olan bu öneri, en muhafazakar büyük öneri olarak kabul edilir ve öncelikle kasalar, tıkanıklık kontrolü ve belirli Lightning iyileştirmelerini hedefler. Nisan 2026 itibarıyla, OP_CTV için Speedy Trial sinyal penceresini belirleyen somut uygulama parametreleri masada yer almaktadır, ancak etkinleştirme için gerekli olan geniş topluluk konsensüsüne henüz ulaşılamamıştır. BlockEden’in Nisan 2026 tarihli sözleşme analizi.
• OP_CAT (BIP-347), Ethan Heilman ve Armin Sabouri tarafından önerilen bu öneri, Satoshi’nin 2010 yılında devre dışı bıraktığı bir opkodunu yeniden etkinleştirecektir. OP_CAT, iki yığın öğesini birleştirir; bu, açıklaması basit ancak etkileri geniş kapsamlıdır. Schnorr imzalarıyla birleştirildiğinde, sözleşme benzeri işlem içgözlemini mümkün kılar. 2024 sonlarında sCrypt tarafından yapılan zincir üstü analize göre, Bitcoin Signet test ağında OP_CAT, APO veya CTV’den önemli ölçüde daha fazla geliştirici işlemi oluşturmuştur. OP_CAT, Liquid Network ve Fractal Bitcoin’de halihazırda aktif durumdadır ve bu opcode ile ilişkili herhangi bir güvenlik açığı bildirilmemiştir. BIP-347'nin resmi bir teklif numarası ve arkasında devam eden araştırmalar mevcut olsa da, ana ağda etkinleştirilmesi için henüz sağlanmamış olan topluluk konsensüsü gereklidir.
• LNHANCE OP_CTV’yi OP_CHECKSIGFROMSTACK (CSFS) ve OP_INTERNALKEY ile bir araya getirerek, etkileşimsiz kanal açılışları ve daha verimli çok taraflı kanal yönetimi dahil olmak üzere Lightning Network kanal oluşturma sürecinde belirli iyileştirmeler sağlamayı hedeflemektedir.

Haziran 2026 itibarıyla bunların hiçbiri Bitcoin ana ağında etkinleştirilmemiştir. Aralarındaki teknik anlaşmazlıkların büyük kısmı çözülebilir niteliktedir. Asıl zor olan sorun, devreye alma mekanizmasıdır. Bitcoin'in soft fork süreci geniş bir konsensüs gerektirir ve sözleşme tartışması, önceki tartışmalı güncellemelerden kalan gerginliği de beraberinde getirir. Tartışmadan açıkça anlaşılan şey, Bitcoin'in komut dosyası katmanının muhafazakar çerçevesi içinde gelişmek için önemli bir potansiyele sahip olduğudur. Üzerinde çalışılan konu, komut dosyası dilinin bir geleceği olup olmadığı değil, sıralama ve topluluk mutabakatıdır.

Sonuç

Bitcoin Script, ağdaki her işlemin altında yatan görünmez altyapıdır. Çoğu kullanıcı bununla doğrudan hiç karşılaşmaz. Cüzdanlar, işleyiş mekanizmasını hiç ortaya çıkarmadan geçerli komut dosyaları oluşturur, bunları imzalar ve yayınlar. Ancak her ödeme, her Lightning kanalı, her zaman kilitli plan ve her çoklu imza kasası, 2009 yılında protokolle birlikte sunulan aynı yığın tabanlı Bitcoin komut dosyası dilinden geçer.

O zamandan bu yana komut dosyası katmanı önemli ölçüde gelişti; P2SH, karmaşık harcamaları pratik hale getirdi; SegWit, ücretleri düşürdü ve Lightning’i mümkün kıldı; Taproot ise Schnorr imzalarını, MAST tabanlı gizliliği ve Tapscript’in ileriye dönük uyumlu opkod tasarımını getirdi. Şu anda aktif olarak tartışılan covenant önerileri, bir sonraki potansiyel aşamayı temsil ediyor. Bunlardan herhangi birinin devreye girip girmeyeceği ve bunun hangi zaman çizelgesinde gerçekleşeceği, 2026 ortası itibarıyla hâlâ tam anlamıyla belirsizliğini koruyor.

Script'i anlamak için geliştirici olmak gerekmez. Ancak Bitcoin’in muhafazakarlığının, kasıtlı sınırlamalarının, yavaş güncelleme sıklığının ve Turing tamlığı olmamasının bir eksiklik olmadığını kabul etmek gerekir. Bitcoin Script’i öngörülebilir kılan özellikler, on altı yıldır konsensüs katmanını temiz tutan özelliklerin aynısıdır.