Bitcoin'in temel tasarım ilkelerinden biri olan UTXO modeli, başlangıcından bu yana blok zinciri alanında önemli bir teknik paradigma olmuştur. Geleneksel hesap bakiyesi modelinin ötesinde alternatif bir yol sağlayarak işlem güvenliği ve izlenebilirliğinin sağlanmasında çok önemli bir rol oynar. Son yıllarda blok zinciri teknolojisinin sürekli evrimi ve genişlemesiyle birlikte, UTXO modelinin kendisi de eUTXO, hücre, Sıkı erişim listesi ve diğerleri gibi sürekli evrim ve genişleme sürecinden geçmektedir.

Bu makale UTXO modelini sade bir dille tanıtmakta ve BTC, Sui, Cardano, Nervos ve Fuel'in UTXO modeli ve uygulama yöntemlerine kısa bir genel bakış sunmaktadır.

UTXO nedir?

UTXO modelini açıklamak için bir örnek kullanacağız:

Alice ve Bob adında iki kişi düşünün, her birinin başlangıçta 5 doları var. Daha sonra bir çatışma ortaya çıkıyor ve Alice'in Bob tarafından 2 doları çalınıyor. Her biri için nihai varlıklar aşağıdaki gibidir:

Alice'in 3$'a, Bob'un ise 7$'a sahip olduğu açıktır. Bu temel aritmetik benzeri muhasebe yöntemi bankacılık sistemlerinde yaygın olarak görülür ve "hesap/denge modeli" olarak adlandırılır. Bu modelde, bir hesabın bakiyesi tek bir sayısal değer olarak mevcuttur.

Alice ve Bob arasındaki servet transferini temsil etmek için UTXO kullanmak gibi hesap modelinden farklı bir yaklaşım benimseyecek olsaydık, açıklayıcı diyagram farklı bir görünüm alırdı:

Bu noktada, Alice'in hala 3 doları ve Bob'un hala 7 doları vardır, ancak bu 7 dolar tek bir sayısal değerle temsil edilmemektedir. Bunun yerine, "5$" ve "2$" olarak ayrılmıştır. Bu alışılmadık yaklaşım size de biraz yabancı geliyor mu? Bu, UTXO olarak bilinen benzersiz muhasebe yöntemidir.

İngilizce kısaltma UTXO, Harcanmamış İşlem Çıktısı anlamına gelir. Bu muhasebe yaklaşımı altında, her zincir içi işlem UTXO'larda değişiklik ve transfer olarak ortaya çıkar. Örneğin, söz konusu işlem olayında, Alice'in başlangıçta sahip olduğu "5 $", UTXO_0 olarak etiketlenen ve harcandı olarak işaretlenecek girdi parametreleri olarak hizmet eder; eşzamanlı olarak, sistem çıktı parametreleri olarak "2 $" (UTXO_1) ve "3 $" (UTXO_2) üretir. UTXO_1 Bob'a aktarılacak ve UTXO_2 Alice'e iade edilecek, böylece Alice ve Bob arasındaki servet transferi tamamlanmış olacaktır.

UTXO modelinde "hesaplar" ve "bakiyeler" gibi açık kavramlar bulunmamaktadır. UTXO, temsil ettiği tutar ve ilişkili işlem endeksi gibi bilgileri kaydederek işlemin yürütülmesine yardımcı olan bir veri yapısı olarak hizmet eder. Her UTXO, belirlenmiş bir sahibi olan harcanmamış bir işlem girdisini temsil eder. Bir işlem gerçekleştiğinde, belirli UTXO'lar girdi olarak kullanılabilir ve bunların yok edilmesi üzerine, işlem çıktıları olarak yeni UTXO'lar üretilir.

Bitcoin hesapları bu şekilde tutar: her işlemde eski UTXO'lar yok edilir ve yenileri oluşturulur. Yok edilen UTXO'ların toplam miktarı, yeni oluşturulan UTXO'ların miktarına eşittir (bir kısmı madencilere işlem ücreti olarak tahsis edilir). Bu, fonların keyfi olarak artırılamamasını sağlar.

UTXO modeli ile Hesap/Bakiye Modeli arasında karşılaştırma

Bir grup kullanıcının aynı anda çok sayıda işlem talebi başlattığını varsayalım. Hesap/denge modeline kıyasla UTXO modeli kullanılarak durum nasıl ele alınır?

Hesap/bakiye modelinde, her kullanıcının kayıtlı bakiye bilgisi olan bir hesabı vardır. Bir işlem gerçekleştiğinde, ilgili hesap bakiyesinin hem "okuma" hem de "yazma" işlemlerini içerecek şekilde güncellenmesi gerekir. Bununla birlikte, iki işlem aynı hesabı içeriyorsa, genellikle okuma-yazma çakışmalarına neden olur ve durum çekişmesine yol açar, bu da kaçınılması gereken bir durumdur.

Geleneksel veritabanı sistemleri genellikle okuma-yazma çekişmesini bir "kilitleme" mekanizması ile ele alır. Böyle bir senaryoda, aynı veriler için çekişmeye neden olan işlemlerin genellikle sıraya girmesi gerekir, bu da eşzamanlı yürütmeyi önler ve işlem işleme verimliliğini azaltır. İşlenmeyi bekleyen çok sayıda işlem olduğunda, bu durum önemli performans darboğazları yaratabilir ve çekişme halindeki işlemler hızlı bir şekilde işlenmeden uzun bekleme süreleriyle karşı karşıya kalabilir.

Hesap bakiyesi modelinin aksine, Bitcoin'in UTXO modeli veri çekişmesi sorunlarını ele almak için daha donanımlıdır. Bu yaklaşımda, her bir işlemin doğrudan işleme tüzel kişiliği artık belirli bir "hesap" değil, daha ziyade bireysel, bağımsız UTXO'lardır. Farklı UTXO'lar birbirlerine müdahale etmediğinden, Bitcoin ağındaki her işlem bağımsız olarak çalışır. Sonuç olarak, Bitcoin ağ düğümleri "kilitlere" ihtiyaç duymadan aynı anda birden fazla işlemi gerçekleştirebilir ve bu da sistem verimini ve eşzamanlılık performansını önemli ölçüde artırır.

Ek olarak, UTXO modelinde, şifreli cüzdanlar genellikle bir işlem başlattıktan sonra kullanıcı için yeni bir adres oluşturur. Bu yaklaşım gizliliği artırarak bir işlemin belirli bir kişiyle ilişkilendirilmesini daha zor hale getirir. Buna karşılık, sabit adresler kullanan hesap/denge modeli, ilişkilendirme analizine daha yatkındır.

Bununla birlikte, UTXO modelinin sınırlamaları vardır. Başlangıçta basit para birimi transferlerini kolaylaştırmak için tasarlanmıştır ve karmaşık iş mantığını işlemek için uygun değildir. Çoklu imza ve zaman kilitleri gibi temel işlevler komut dosyası dilleri kullanılarak uygulanabilirken, Bitcoin'in UTXO'sunun kaydedebildiği minimum durum bilgisi, onu daha karmaşık işlemlerin üstesinden gelme konusunda daha az yetenekli hale getirmektedir.

Bitcoin'in UTXO'sunun sınırlamaları dolaylı olarak "Ethereum "un ortaya çıkmasına katkıda bulundu. Bitcoin Magazine'e en erken katkıda bulunanlardan biri olan Vitalik, Bitcoin'in eksikliklerinin farkındaydı. Çoğu kişi için anlaşılması daha kolay olan hesap/denge modeli, UTXO'nun zengin durum uygulamalarını ele alırken karşılaştığı zorlukları ele almaktadır. Vitalik'in Ethereum whitepaper'ında belirttiği gibi:

UTXO harcanabilir ya da harcanmayabilir; çok aşamalı sözleşmeler ya da bunun ötesinde başka bir dahili durumu koruyan senaryolar için hiçbir fırsat yoktur. Bu da çok aşamalı opsiyon sözleşmelerinin, merkezi olmayan borsa tekliflerinin veya iki aşamalı kriptografik taahhüt protokollerinin (güvenli hesaplama ödülleri için gerekli) yapılmasını zorlaştırır. Ayrıca UTXO'nun yalnızca basit, tek seferlik sözleşmeler oluşturmak için kullanılabileceği ve merkezi olmayan kuruluşlar gibi daha karmaşık "durumlu" sözleşmeler için kullanılamayacağı anlamına gelir ve meta-protokollerin uygulanmasını zorlaştırır. Değer körlüğü ile birleşen ikili durum, bir diğer önemli uygulama olan para çekme limitlerinin de imkansız olduğu anlamına gelmektedir.

UXTO Modelinin Uygulanması, Optimizasyonu ve Genişletilmesi

UTXO modelinin çeşitli uygulamalarını ve optimizasyonlarını incelemeden önce, avantajlarını korurken iyileştirme alanlarını analiz edelim. Bunlar aşağıdaki şekilde özetlenebilir:

1. UTXO'larda depolanan durumun anlamını soyutlama.

2. Devlet mülkiyetinin soyutlanması.

3. UTXO'ları paylaşırken durum çekişmesi sorunlarını çözme.

BTC'de durumun tek anlamı token miktarıdır, sahiplik tipik olarak açık anahtarlar kullanılarak tanımlanır ve BTC dApp'ler için tasarlanmadığından durum çekişmesi kapsamlı bir şekilde ele alınmaz.

Sui

Sui, geliştiricilere iki tür nesne sağlar: OwnedObject ve SharedObject. İlki UTXO'ya (özellikle geliştirilmiş bir versiyon) benzerken, ikincisi hesap/denge modeliyle karşılaştırılabilir. Her ikisi de aynı anda kullanılabilir.

Bir Nesne paylaşılabilir, yani herkes o Nesneyi okuyabilir veya yazabilir. Değiştirilebilir OwnedObject'in aksine (yalnızca bir yazarla), SharedObject okuma ve yazmaları sıralamak için fikir birliği gerektirir.

Diğer blok zincirlerinde her Nesne paylaşılır. Ancak, Sui geliştiricileri genellikle belirli kullanım durumlarını uygulamak için OwnedObject, SharedObject veya her ikisinin bir kombinasyonunu kullanmayı seçebilirler. Bu seçim performansı, güvenliği ve uygulama karmaşıklığını etkileyebilir.

Sui'de Sahipli Nesneler UTXO'lara benzer ve üzerlerinde yalnızca sahipleri işlem yapabilir. Nesnelerin sürüm numaraları da vardır ve bir nesnenin sürümü sahibi tarafından yalnızca bir kez harcanabilir. Bu nedenle, bir nesnenin bir sürümü esasen bir UTXO'ya karşılık gelir.

Durum çekişmesi sorunlarıyla ilgili olarak, Sui bunları SharedObjects'teki özel işleme (yerel sıralama, Fuel'e benzer) yoluyla ele alır.

Cardano

Cardano, eUTXO olarak bilinen genişletilmiş bir UTXO modeli kullanmaktadır. eUTXO, Bitcoin UTXO modelinin avantajlarını korurken daha fazla programlanabilirliği destekler.

Cardano'da devletin anlamı senaryolar aracılığıyla daha da genişletilmiş ve devletin mülkiyeti daha genel bir şekilde tanımlanmıştır. UTXO setleri durum çekişmesi sorunlarını en aza indirmek için kullanılır. Özellikle, eUTXO iki açıdan geliştirilmiştir:

1. eUTXO modeli daha genelleştirilmiş adresler içerir. Bu adresler yalnızca açık anahtarların karmasına dayalı olmayıp, eUTXO'nun harcanabileceği koşulları belirten herhangi bir mantığa dayalı olarak tanımlanabilir ve devlet sahipliğinin programlanabilirliğini sağlar.

2. Adreslere ve değerlere ek olarak, çıkışlar (neredeyse) herhangi bir veriyi taşıyabilir ve durumun anlamını komut dosyaları aracılığıyla programlamaya izin verir.

Daha spesifik olarak eUTXO, kullanıcıların UTXO'lara Datum olarak adlandırılan JSON benzeri bir formatta rastgele veriler eklemesine olanak tanır. Datum, geliştiricilerin belirli UTXO'larla ilişkili komut dosyaları için durum benzeri işlevsellik sağlamasına olanak tanır.

Ayrıca, Cardano'daki işlemler, itfa ediciler olarak bilinen belirli kullanıcılarla ilgili parametreler taşıyabilir. Redeemer, işlemi başlatanın UTXO'ların nasıl kullanılacağını tanımlamasına olanak tanır ve dApp geliştiricileri tarafından çeşitli amaçlar için kullanılabilir.

Bir işlem doğrulandığında, doğrulama komut dosyası Datum, Redeemer ve işlem verilerini içeren bağlamı kullanarak çalışır. Bu kod, koşullar karşılandığında UTXO'ları kullanma mantığını içerir.

eUTXO'nun genişletme görevlerini hala komut dosyaları aracılığıyla gerçekleştirdiğini ve geleneksel "akıllı sözleşmeler" kavramından önemli ölçüde farklı olduğunu belirtmek gerekir (kurucusu Charles Hoskinson, buna "programlanabilir doğrulayıcı" demeyi önermektedir, ancak "akıllı sözleşmeler" terimi piyasada daha yaygın olarak kabul görmektedir).

Nervos

Nervos'ta (CKB), durumun anlamı TypeScript tarafından soyutlanır ve durumun sahipliği bir kilit komut dosyası tarafından soyutlanır. Hücre kodu biçimindeki basit bir UTXO optimizasyon modeli aşağıdaki gibidir:

pub struct CellOutput {

    pub kapasitesi: Capacity,

 pub data: Vec<u8>,

 pub lock: Script,

 pub type_: Option<Script>,

}

Durum çekişmesi konusuna gelince, CKB şu anda kullanıcıların işlemin amacını belirten kısmi bir UTXO önerebildiği ve daha sonra eşleştiricilerin bunları tam bir işlemde topladığı Açık İşlem araştırmasını ilerletmektedir.

Nervos'un hücre modeli UTXO'nun "genelleştirilmiş" bir versiyonudur ve Jan, Nervos forumunda ayrıntılı bir açıklama yapmıştır:

Katman1'in odak noktası durumdur ve tasarım hedefi olarak Katman1 ile CKB doğal olarak duruma odaklanır.

Ethereum, işlem geçmişini ve durum geçmişini iki boyuta ayırır; burada bloklar ve işlemler, durumun kendisinden ziyade durum geçişlerini tetikleyen olayları temsil eder. Bunun aksine, Bitcoin protokolü işlemleri ve durumları tek bir boyutta birleştirir-işlemler durumdur ve durum da işlemdir. Devlet merkezli bir mimaridir.

Aynı zamanda CKB, sadece nValue'yu değil, değerli görülen ve uzun vadeli koruma için konsensüsle onaylanan tüm verileri doğrulamayı ve korumayı amaçlamaktadır. Bitcoin'in işlem çıktısı yapısı bu amaç için yetersizdir, ancak bize bolca ilham vermiştir. nValue'yu genelleştirerek ve tamsayıları depolayan bir alandan herhangi bir veriyi tutabilen bir alana dönüştürerek, daha genelleştirilmiş bir "CTxOut" veya Cell elde ederiz.

Bir Hücrede, nValue iki alana dönüşür: kapasite ve veri. Bu alanlar birlikte bir depolama alanını temsil eder; burada kapasite, alanın bayt cinsinden boyutunu gösteren bir tamsayıdır ve veri, durumun depolandığı yerdir ve herhangi bir bayt dizisini barındırabilir. Bu mutabakat alanının sahibinin kim olduğunu ifade eden scriptPubKey sadece isim değişikliğiyle kilit haline gelir; sadece kilit komut dosyasının başarıyla yürütülmesi için parametreler (imza gibi) sağlayabilen kişi bu Hücredeki durumu "güncelleyebilir". Tüm CellOutput tarafından işgal edilen toplam bayt sayısı kapasiteden az veya kapasiteye eşit olmalıdır. CKB'nin çok sayıda Hücresi vardır ve bunların koleksiyonu CKB'nin mevcut durumunun tamamını oluşturur ve sadece belirli bir dijital para biriminden ziyade paylaşılan bilgiyi depolar.

İşlemler hala durum değişikliklerini/göçlerini temsil etmektedir. Durum değişikliği veya hücre içeriğinin "güncellenmesi" aslında yok etme ve oluşturma yoluyla gerçekleştirilir (orijinal hücrenin içeriğini doğrudan değiştirerek değil). Her işlem bir grup hücreyi etkili bir şekilde yok ederken aynı anda yeni bir grup hücre yaratır. Yeni oluşturulan hücrelerin yeni sahipleri vardır ve yeni veriler depolarlar, ancak yok edilen toplam kapasite her zaman yaratılan toplam kapasiteden büyük veya eşittir, böylece hiç kimse kapasiteyi keyfi olarak artıramaz. Kapasite transfer edilebildiği ancak keyfi olarak artırılamadığı için, kapasiteye sahip olmak, karşılık gelen miktarda mutabakat durum alanına sahip olmakla eşdeğerdir. Kapasite, CKB ağındaki yerel varlıktır. Bir hücrenin yok edilmesi, harcanmamış Bitcoin UTXO'larının harcanmış hale gelmesine ve blok zincirinden fiziksel olarak kaldırılmamasına benzer şekilde, onu yalnızca "yok edildi" olarak işaretler. Her Hücre yalnızca bir kez yok edilebilir, tıpkı her UTXO'nun yalnızca bir kez harcanabilmesi gibi.

Bu modelin özellikleri şunlardır:

1. Devlet birincil öneme sahiptir.

2. Mülkiyet devletin bir niteliğidir ve her devletin tek bir sahibi vardır.

3. Devletler sürekli olarak yok edilir ve yaratılır.

Bu nedenle hücre, UTXO'nun genelleştirilmiş bir versiyonudur.

Yakıt

Fuel, Sözleşme UTXO kavramına dayalı bir UTXO optimizasyonu olan Sıkı Erişim Listesi modelini benimser.

Daha önce tanıtıldığı gibi, BTC'deki geleneksel UTXO'nun yalnızca iki özelliği vardır: coin miktarı ve sahibi. Buna karşılık, Sözleşme UTXO, coin miktarı, sözleşme kimliği, sözleşme kodu karması ve depolama kökü dahil olmak üzere ek temel özellikler sağlar.

Durumsuz bir yürütme modeli kullanılıyorsa, yalnızca Sözleşme UTXO'su sözleşme kodu karması ve depolama kökü gerektirir. Durum bilgisi içeren bir yürütme modelinde, bu alanlar Sözleşme UTXO'sunda atlanabilir, ancak ayrı bir Depolama Öğesi UTXO türüne ihtiyaç vardır. Bir anahtar-değer depolama veritabanında anahtar olarak hizmet veren her UTXO için benzersiz bir tanımlayıcı olan UTXO ID, UTXO'nun çıkış noktasından veya varyantından (örneğin, çıkış noktasının ve alanlarının hash'i) oluşturulur.

Bu modelde Sözleşme UTXO, akıllı sözleşmelere benzer şekilde, herkes tarafından çağrılabilir.

Fuel'in komut dosyalarından ziyade akıllı sözleşmelere daha yakın işlevler sağladığını belirtmek önemlidir. UTXO modelinin kendi sınırlamaları, özellikle UTXO çekişme sorunlarının ele alınmasında bir VM ile uygulama geliştirmeyi zorlaştırmaktadır. Genel olarak üç çözüm vardır: birincisi, rollup gibi zincir dışı işlemler; ikincisi, Fuel'in kullandığı ek işlerin önceden sıralanması; üçüncüsü, her kullanıcının kısmi işlemler önerebileceği ve bir eşleştiricinin (sıralayıcıya benzer) bunları tam işlemler halinde birleştirdiği CKB'de yukarıda bahsedilen Açık İşlem. BTC'de buna karşılık gelen çözüm PBST'dir.

Sonuç

Bu makalede, UTXO'nun temel ilkelerini anlamış, Ethereum'un hesap/denge modeline kıyasla modelinin güçlü ve zayıf yönlerini fark etmiş ve UTXO kavramı ve ilgili uzantıları hakkında daha net bir fikir edinmiş bulunuyoruz.

Bitcoin'in temel tasarım ilkelerinden biri olan UTXO modeli, işlemlerin güvenliğinin ve izlenebilirliğinin sağlanmasında çok önemli bir rol oynamaktadır. Blok zinciri teknolojisinin sürekli gelişimi ve genişlemesiyle birlikte, UTXO modeli gelişmekte (EUTXO, hücre, Sıkı Erişim Listesi gibi) ve dijital varlıkların işlemi ve yönetimi için daha fazla olanak sağlamaktadır. UTXO konseptinin ve ilgili uzantılarının derinlemesine araştırılması ve anlaşılması yoluyla, blok zinciri teknolojisinin özünü daha iyi kavrayabilir, gelecekteki yenilikler ve uygulamalar için daha sağlam bir temel atabiliriz.

Sorumluluk Reddi：

1. Bu makale[极客 Web3] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazar[0xAyA]'ya aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.