Öncelikle bazı kavramların açıklamaları:
- pubkey: public key. Private key’e çiftlenen anahtar.
- IOU:“I owe you” kısaltması. “Sana borçluyum” demektir. Siz merkezi bir borsaya Bitcoin (BTC) veya bir kripto para gönderdiğinizde karşı taraf size o miktarda ve o birimde para borçludur.
- Token: Kendine ait blokzinciri olmayan dijital para birimidir. Tam Türkçe karşılığı jeton olarak kullanılabilir ancak kavramsal karşılığı oluşturulmamıştır.
Bu cümlede “IOU Token” ile merkezi borsa sizin gönderdiğiniz para miktarı ve biriminde “sanal” veya “gölge” para üreterek sizin borsa üzerindeki hesabınıza tanımlar.
- Trade:Alış/satış, takas gibi anlamları vardır. Bu alanda trade etmek, bir coin’i başka bir coin veya değer (USD, Euro, TL gölgeleri) ile değiş tokuş etmek demektir. Değiş tokuşa konu olan coin’lerin miktarlarının oranı ise fiyattır.
- Trader: Trade gerçekleştiren taraf(lar).
- MultiGateway: Çoklu geçiş kapısı demektir. Merkezi borsalarda oluşturulan gölge (sanal veya vekil) token’lar gibi, başka blok zincirleri üzerinde de başka bir blok zinciri coin’inin gölgesi oluşturulabilir. Bunun için çeşitli geçitler kullanılır. Bu geçitler birden fazla coin’i destekler ise çoklu geçit olarak tanımlanır.
- Proxy: Kelime anlamı olarak vekil demektir. Sizin merkezi borsaya gönderdiğiniz BTC veya herhangi bir coin için aynı miktarda vekil (gölge) coin tayin edilir. Siz borsa içerisinde elinizdeki BTC’yi verip karşılığında bir miktar ETH aldığınızda (trade) size tayin edilen yine gölge coin’dir. Yaptığınız bu değiş tokuşun herhangi bir blokzinciri üzerinde kaydı yoktur. Borsa hesabınızda gördüğünüz ETH miktarı, Ethereum blok zinciri üzerinde size ait değildir.
- SPV: Simplified Payment Verification (Basitleştirilmiş Ödeme Doğrulama) kısaltmasıdır. Bitcoin Whitepaper’ında Satoshi Nakamoto bu konuyu anlatmıştır.
- Electrum: Electrum ise hafif bir Bitcoin cüzdanı uygulamasıdır. Kasım 2011’de Thomas Voegtlin tarafından oluşturulmuştur. Ücretsizdir ve MIT lisansı ile yayımlanmıştır.
SPV Electrum ile desteklenen coin’lerin bütün blokzinciri kayıtlarını bilgisayarınıza indirmenize gerek
kalmaz.
- Daemon: Art süreç. Çoklu görev yapabilen bilgisayar sistemlerinde, kullanıcının direkt kontrolünde olmayan ve arkaplanda kendiliğinden çalışan programlara verilen isimdir. Bir coin’e ilişkin cüzdan indirdiğinizde, bütün blokzinciri verisi bilgisayarınıza iner ve bir art süreç çalışarak cüzdanı sürekli güncel tutar.
- İzole (Abstracted): Yazar burada “abstracted” kelimesini kullanır. Abstracted kelimesi şu şekilde açıklanabilir: Yazılım alanında, bir abstraction katmanı veya abstraction seviyesi bir kısım işlevlerin uygulama detaylarının, platformdan bağımsız ve platformlar arası çalışmayı mümkün kılan endişelerin ayrılmasına imkân sağlayacak şekilde saklanması yoludur. Yazılım modellerinde abstraction katmanlarının kullanım örnekleri; ağ protokolleri için OSI modeli, OpenGL ve diğer grafik kütüphaneleridir. Burada abstraction kelimesinin izole şeklinde çevrilmesi uygun görülmüştür.
- API: Application Programming Interface kısaltmasıdır. Uygulama programlama arayüzü olarak çevrilebilir.
- Orderbook: Emir defteri şeklinde çevrilebilir. Trade yapmak isteyen tarafların miktar ve fiyat belirterek tanımladıkları alış ve satış teklif/emirlerinin kayıt edildiği listedir.
- listunspent: Bir BarterDEX API komutudur. Detaylı bilgi buradan alınabilir. Kısaca açıklamak gerekirse, BarterDEX, trade için toplam bakiyeyi kullanmak yerine UTXO çiftlerini kullanır. Bunun içinse bakiye bölünerek adresi 1x, 1.2x & 0.1x oranlarında fonlanır. Bu atomik takas protokolünün doğası gereği ve her atomik takas için iki UTXO’ya ihtiyaç duyulması nedeniyle yapılan bir işlemdir. Örneklemek gerekirse, bir alım işlemi yapmak için ihtiyaç duyduğunuz rakam 75 kuruş olsun. Bunun için 1 TL verip 25 kr geri alarak iki yönlü işlem yapmaktansa 50 kr ve 25 kr vererek tek seferde işlemi tamamlayabilirsiniz.
/listunspent komutu cüzdanın akıllı adresindeki UTXO’ların listesini geri döndürür.
- JSON: “JavaScript Object Notation” bütün programlama dilleri arasında, yapılandırılmış veri değişimini kolaylaştıran bir metin biçimidir.
- CLTV (CheckLockTimeVerify): Bitcoin transaction’lar için script sistemi kullanır. Script kelimeleri ise opcode, komut veya fonksiyonlardır. CLTV de bir opcode’dur. Yani Bitcoin işlemlerinde kullanılan bir yazılım komutudur diyebiliriz.
CLTV opcode’u çağırılınca, CLTV ile birlikte verilen zaman parametresinin, transaction üzerindeki nLockTime verisine eşit veya ondan daha büyük olması gerekir. Bir transaction sadece geçerli bir blokta bulunabileceği için, eğer transaction’daki zaman geçmişse CLTV’de belirtilen zaman kriteri sağlanmamış olur ve geçerli bir bloğun parçası olamaz.
- gettxout: Bir Bitcoin API komutudur. Çağrıldığında bir UTXO’ya ilişkin detayları geri döndürür.
- RPC: Remote Procedure Calls kısaltmasıdır. Uzaktan Prosedür Çağrıları diye çevrilebilir.
- Curve25519: Kriptografide, Curve25519, 128 bitlik emniyet sunan ve Diffie-Hellman eliptik eğrisi (ECDH) anahtar anlaşma planıyla birlikte kullanılmak üzere tasarlanan bir eliptik eğridir. En hızlı ECC eğrilerinden birisidir ve bilenen bir patent ile koruma altında değildir. Buradan detaylı okuma yapılabilir.
- Privacy: Mahremiyet, gizlilik gibi kelimelere çevrilebilir. Burada “privacy” kelimesi ile yapılan işlemlerin görülebildiği, takip edilebildiği ancak işlemi yapan kişinin kim olduğunun tespit edilememesi anlamında kullanılmıştır. Metinde BarterDEX’in privacy sunmadığı ve işlemlerin IP adresinize kadar takip edilme ihtimali olduğunu belirtir. Bu noktada okuyucular privacy ile anonymity arasındaki farka dikkat etmelidir. “Anonymity” kimliğinizin gizli kalması, “privacy” ise işlem içeriğinin gizli kalması demektir.
- JUMBLR: Komodo’nun privacy için oluşturduğu bir protokoldür. Kabaca, coin işlem değerlerini zksnark protokolü ile maskelerken, birden fazla coin’i birbiri arasında birden fazla parça ile takas ederek takip edilemez hale getirir. Detaylı bilgi için buraya bakabilirsiniz.
- DEX: Komodo blokzincirine bağlı bir varlık zinciridir. DEX sahipleri BarterDEX üzerinde yapılan trade’lerden alınan dexfee’lerden kȃr payı şeklinde faydalanır.
- IGUANA: Iguana bir kripto yazılımı alet seti gibi düşünülmelidir. Baş geliştirici JL777 tarafından sıfırdan oluşturulmuş, hemen hemen bütün Komodo platform projelerinde kullanılan prosedürlerden oluşan bir kod bütünüdür.
- Withdraw: BarterDEX API komutudur.
- Passphrase: Password şifre kelimesi demektir, passphrase ise şifre cümlesi gibi düşünülebilir. Birden fazla kelime oluşturacağınız metin sizin passphrase’inizdir.
- Privkey: Private key. Coin değerinizi tutan size özel anahtar. Pubkey ile birlikte çifttir.
- UTXO: Unspent Transaction Output kısaltmasıdır. Harcanmamış Gönderi Çıktısı olarak çevrilebilir. Bitcoin üzerinde para göndermeyi birine çek yazmak gibi düşünebilirsiniz. Birisi size bir çek gönderdiğinde, bankaya gidip ben bunun yarısını istiyorum demezsiniz. Hepsini çeker ve kendi hesabınıza yatırırsınız. Ya da daha sonra başkasına gönderilmek üzere siz yeni çek yazarsınız. Bitcoin işlemlerinde de UTXO çek demektir. Bir gönderimde 1 veya daha fazla çek harcarsınız, yani nakte çevirirsiniz (aslında bu çekler UTXO’lardır) ve bu harcanan fonlardan 1 veya daha fazla UTXO’ları yeni adreslere gönderebilirsiniz. Bir gönderide harcadığınız UTXO’lar Vin (girdi), sizin oluşturduklarınız Vout (çıktı) olarak adlandırılır.
Diyelim ki size 10 BTC geldi. Elinizde 10 BTC’lik bir çek var demektir. Arkadaşınıza 7 BTC göndereceksiniz, bu durumda iki adet çek yazarsınız, birisinde 7 BTC ve arkadaşınızın adresi, diğerinde 3 BTC ve kendi adresiniz. UTXO, Bitcoin’in çalışma sisteminin önemli bir parçasıdır.
Özet
Bu makalede, insanların, karşı taraf risklerinden arındırılmış olarak coin’lerini takas edebilecekleri desantralize borsa uygulamasını açıklayacağız. Tam özellikli bir hizmet; desantralize emir eşleme, takas sonlandırma ve uzlaşmaya ihtiyaç duyar. Emir eşleme düşük seviye pubkey1’den pubkey’e mesajlaşma protokolü yoluyla yapılır ve nihai uzlaşma bir “atomik zincirler arası protokolü” yoluyla yapılır. Herhangi bir borsa gibi, desantralize alternatifi de yeterli likidite için likidite sağlayıcılarına (LP: liquidity providers) ihtiyaç duyar.
Giriş
Para, kişiden kişiye, özgürce ve emniyetli bir şekilde el değiştirmelidir ve bu değişim için halihazırda en pratik yöntem merkezi bir borsadır. Böylesi merkezi bir çözüm, takas edilecek fonların, borsa hizmeti sağlayıcı tarafından desteklenen IOU2 token3’lara dönüştürülmesini gerekli kılar. Bu nedenle, müşteriler her daim, içeriden hırsızlıkla veya dışarıdan borsanın güvenliğinin aşılması (hack) yoluyla varlıklarının çalınması riski altındadır. Bu risklerin bertaraf edilmesi için, desantralize bir alternatifin oluşturulması gereklidir.
Trade4 hacmi tüm borsalar arasından birkaç borsada kümelenmeye meyleder ve bunun için iyi de bir neden vardır. IOU token’ları ile çalışan borsalarda hızlı trade avantajı borsa trader5’larını çeker ve tüccarlar likidite getirir, bu sayede en iyi fiyatlar oluşur ve bu da daha çok trader çeker. Bu ağ etkisi, küçük borsaların tümünü – merkezi ve desantralize – likidite eksikliğine mahkum ederken birkaç merkeziborsa trade hacimlerini domine eder.
2014 yılında MultiGateway6 olarak adlandırılan bir hizmet ile NXT Varlık Borsası’nın istifade ettiği desantralize bir takas ortamı oluşturuldu. NXT Varlık Borsası ile, borsa dışı kripto paraların, Bitcoin gibi, proxy7 token’ların jetonlarını kullanarak desantralize takas yapmak mümkündür. Bu melez çözüm diğer birçok blokzinciri platformları tarafından artarak kullanılmaktadır.
Bu çeşit bir çözümün sorunu, merkezi bir borsanın hızını bir şekilde yakalayamamasıdır. Bir diğer sorun ise sistem dışı kripto paraların desantralize bir şekilde saklanmaması, en iyi ihtimalle dağıtık şekilde saklanmasıdır ki bu da kullanıcıların karşı taraf riskini bir dereceye kadar taşımasını gerektirir. Bu sorunlar, sistem dışı kripto paraların ağ geçitleri ile proxy token’lara dönüştürülmesi ile birlikte değerlendirildiğinde, bu çözümü kullanışsız bir çözüm yapar.
Varılan sonuç şudur ki; hızdan yoksun desantralize bir alternatif, mevcut merkezi borsaların uygunluğu ile rekabet edemez ve sadece karşı taraf riskini azaltmak da likiditeyi çekmek için yeterli değildir.
BarterDex’te Uygulanan İyileştirmeler
BarterDex yılların geliştirme ve yinelenen versiyonların sonucudur. Her yineleme, geniş ölçekli benimsenme hedefinin başarılması için gereksinim duyulan işlevselliğin sonraki katmanını ekler.
Bu yinelenen döngüler ile, Barderdex, SPV8 Electrum9 tabanlı coinlere ek olarak yerel coin daemon10’ları çalıştırılan birçok normal Bitcoin protokollü coinler için destek ekler. Bir coinin “SPV”liliği, içeride öyle izole11 edilmiştir ki birçok API12 çağrıları, SPV mod coinler ve yerel coin daemonları için şeffaf şekilde çalışır. “İlk tamamlanan trade’i alır” kuralı ile çalışan, aynı fonun birden fazla orderbook13 üzerinde satış emri (ask) olarak kullanılmasına izin veren, Likidite Çoğaltma (Liquidity Multiplication) yöntemini de uygular. Bu 100 BTC değerindeki fonların, binlerce BTC değerinde likidite yaratmasını sağlar ve aşağıda yüklü satış bekleyen trader’lara özel bir avantaj sağlar. Bu özellik diğer herhangi bir borsa tarafından uygulanabilecek bir özellik olmakla birlikte, eğer uygulamış bir borsa varsa da oldukça azdır. Bütün orderbook girişleri %100 gerçek fonlarca desteklenmiştir ve aynı fonlar 25 farklı orderbook’un da bir parçası olabilir.
Electrum API çağrısı açık istisnası ve “listunspent”14 çağrıları gibi çağrılar için geri döndürülen JSON15’daki bazı farklılıklar dışında, bütün coinler için aynı API modelini oluşturmak mümkündür. Herhangi özel bir sıralama olmaksızın, paremetreleri ile birlikte API çağrıları listesi aşağıdadır.
BarterDEX API
Lütfen, detaylı BarterDEX API dokümanı için buraya tıklayın.
Ayrıca, farklı daha düşük seviye transaction (işlem) ve blok farklılıkları olan coin’ler genel bir coin modeline haritalanır ve tüm API için sadece “coin” sembolü belirtmek aynı cevabı almak için yeterlidir. Bitcoin protokolü istenir, fakat ChecckLockTimeVerify (CLTV)16 aktif olmayan, daha yaşlı coin’ler bile likitide alıcı tarafta çalışabilir.
Bir coin’in yerel modda çalışması için gereksinimler, “gettxxout”17 RPC18 çağrısının olması ve CLTV opkodu varsa hem likidite sağlayıcı (bob) hem de likidite alıcı (alice) olabilir. SPV kullanan coinler için, genel ağ performans sebepleri ile, şimdilik, sadece likidite alıcı modu desteklenmektedir. Ayrıca, mantıken, ciddi bir trader, trade ettiği coin’ler için daemon kuracak kadar da ciddi olmalıdır.
Emir Eşleme
Atomik takas detaylarına girmeden önce belirtmek gerekir ki, BarterDEX’in oldukça kritik olan diğer bir özelliği desantralize orderbook olmasıdır. Bunu başarmak için, BarterDEX, tam iletim ucu (full relay node) ve iletim yapmayan bir ucun (node that doesn’t relay) benzeri olan, özel bir “kişiden kişiye” (peer to peer) ağ oluşturur. Bu ağ üzerindeki yük orderbook’ların hiyerarşik iletimi ve verinin getirilmesinin kombinasyonu ile en aza indirilir. Aynı zamanda, BarterDEX ağına tam bağlanabilen uçların sayısını azami miktara çıkarabilmek için veriyi getirecek birçok farklı yöntem vardır.
Bu yöntemlerden birisi, tamamen bağımsız bir tohum uçları kümesi ile ağı sınıflandırarak tamamen ayrı bir BarterDEX uçları kümesi oluşturmak mümkündür. Bu BarterDEX’in rastgele seviyelere ölçeklenmesini sağlar, eğer bir ölçekleme sınırına erişilirse, diğeri ile direkt bir bağlantısı olmayan ayrı bir ağ oluşturmak yeterlidir. Böylesi bir ölçekte, emir defterlerinde, özellikle de her bir referans coin için bölümleme yapılmışsa, oldukça fazla envanter olduğu varsayılır. Birbirinden bağımsız BarterDEX ağlarındaki emir defteri girişlerinde çapraz işlem yapılması gerektiğinde, özel köprü uçların istenilen girişleri bir ağdan diğerine taşıması mümkündür.
BarterDEX ağındaki adresleme Curve2551919 pubkey ile yapıldığı için, bir ucun IP adresi önemli değildir ve iletim yapmayan uçlar için BarterDEX protokol paketinin asla bir parçası değildir. Sadece kötü niyeli bir iletim ucu, düşük seviyede IP adreslerini görüntüleyerek pubkey’ler ile ilişkilendirebilir. Ancak, BarterDEX blokzinciri kullanarak trade yapmakla ilgilidir, bu da halka açık bir faaliyettir. BarterDEX kullandığınızda herhangi bir privacy20 olduğunu varsaymayınız. Mahremiyet için JUMBLR21 kullanmalısınız.
İsteyen herkes tam iletim ucu çalıştırabilir, bunu yapmak için özel bir ödeme gerekmez ve daha çok bant genişliği ister.
Ancak, tam iletim ucu olarak diğer tüm uçlardan daha iyi bağlantınız olur ve daha yüksek ihtimalle bir takası başlatır ve tamamlarsınız. Tam uç olarak elde edilen işlevsellikte oluşan bu artış aktif tüccarlar için ve DEX22 varlığının önemli sahipleri için yeterli olacaktır, yeterli miktarda tam uç olduğundan emin olmak iyi bir şeydir.
Bir “iletim yapmayan uç”, “tam iletim ucu”nun yapabildiği her şeyi yapabilir, dolayısıyla uçların önemli bir çoğunluğunun iletim yapmayan uç olacağını bekliyoruz ve bu da BarterDEX ağının çok geniş bir toplam uç sayısına erişeceğini gösteriyor. 100 tam uç, binlerce hatta on binlerce iletim yapmayan ucu destekleyebilir, pratikte o sayılara ulaşılmamış olduğu için, gerçek dünya sınırlamalarının nasıl olacağınıgörmek için beklemek zorundayız.
BarterDEX’in üçüncü önemli kısmı ise çatallandırıldığı iguana23 kod tabanıdır. Bu, özel bir cüzdanı mümkün kılar, öyle ki tamamıyla kendi içinde barınan kaynak kodu kümesi kullanılarak oluşturulan tüm desteklenen coin’lerle çalışabilir. Tüm atomik takas protokol işlemleri iguana kodu tarafından oluşturulan ve imzalanan özel ham işlemlerdir. “Withdraw”24 API komutu kullanılarak BarterDEX API kullanan, genel amaçlı bir cüzdan oluşturulabilir. Passphrase25 ile oluşturulan privkey26 kullanır, dolayısıyla BarterDEX’in yapılandırdığı bir wallet.dat dosyası yoktur ve sadece aktif privkey’den türetilen tek adresi kullanır. Bütün coin’ler bir adresi alır fakat hepsi aynı privkey’e dayanır. Bu akıllı adreste toplanan fonlar, otomatik olarak trade edilebilir olurlar. Dikkat edin, tüm fonlar sadece passphrase’e sahip kullanıcı tarafından harcanabilir ve privkey herhangi bir yerel cüzdana eklenebilir. Bu normal coin daemon’unun transaction yapmasını sağlar, ancak dikkat edin, bekleyen başka bir trade’de kullanılan UTXO27’yu kullanmamalısınız!
Atomik Takaslar
BarterDEX bitcointalk girişinde anlatılan Tier Nolan Protokolü’nü kullanır.
Atomik Takas Protokolüne Genel Bakış
Yazı oldukça teknik olmasına rağmen, atomik takas protokolü seçerken yapılan tercihlere ilişkin çok iyi bir arkaplan verir. Dikkat edilmesi gereken önemli nokta, protokolün her adımının sonraki adıma geçerken artıları/eksileri vardır ve protokol nerede durursa dursun, protokolün bütün tarafları, protokolden almaları gereken ile çıkmalıdır. Anlaşılmalıdır ki eğer protokolü takip etmezseniz, bazı cezaları ödemek durumunda kalırsınız.
Bunu başarmak için, likidite sağlayıcı, ona “Bob” diyelim, protokolü tamamlamayı garantilemek için bir bakiyeye sahip olmalıdır. Bu demektir ki Bob, atomik takas yapabilmek için iki UTXO’ya sahip olmalıdır. Alice de iki UTXO’ya ihtiyaç duyar, ancak onun UTXO’su orderbook’a gereksiz girişleri engellemek için kullanılacak olan dexfee27’dir.
Bu olmadan, Alice sınırsız sayıda atomik takas başlatabilir ve Bob’lar ise fonlarını geri alabilmek için zaman periyodunun bitmesini beklemek zorunda kalacaktırlar. Dexfee ile, alice’in böylesi bir kötü davranışının finansal bir maliyeti olması ve aynı zamanda Alice için bir kazanç da olmaması nedeniyle bu şekilde kasıtlı gereksiz girişlerin yapılmayacağını umuyoruz.
Her adımın validasyon detaylarını yok sayarsak, bir atomik takas 7 işlemden oluşur, bazı durumlarda daha az olabilir. Aşağıdaki sıralama iki taraf için tamamlanan TAKAS dizisini göstermektedir:
Alice dexfee gönderir.
Bob bobdeposit gönderir.
Alice alicepayment gönderir.
Bob bobpayment gönderir.
Alice bobpayment harcar.
Bob alicepayment harcar.
Aob kendi bakiyesini yeniden fonlar.
2 işlemde yapılabilecekken 7 adımda takas tamamlamak pek verimli gibi görünmese de, bu işlemlerin güvensiz olması ve her adımda bir sonraki adıma gitmek için bir çıkar olması ve işler nerede durursa dursun iki tarafından doğru miktarlarla işten çıkması gibi karakteristikler için gereklidir.
Eğer bir adımda durulursa ne oluyor görelim:
Alice dexfee gönderir. Eğer Bob bobdeposit göndermez ise, Alice’ten bir dexfee eksilmiş olur ki bu da işlem tutarının 1/777’idir. Bu Bob’a kötü bir itibar verir ve hızlı bir şekilde kimse Bob ile işlem yapmak istemeyecek duruma gelecektir. Bob’un yeterli bakiyeyi göndermeme sıklığı düştükçe, ekstra dexfee’de minik bir sorun olarak kalacaktır. Eğer bir Alice ucu kısmen büyük miktarlarda dexfee kaybına uğrarsa, kaybın karşılanması için acil eylem planları mevcuttur.
Bob bobdeposit gönderir. Eğer Alice alicepayment göndermezse, bu defa Alice sadece dexfee’sini kaybetmiş olmaz aynı zamanda itibar kaybına uğrar ve kimse Alice ile işlem yapmak istemez. Bunun da çok sık olmayacağını umuyoruz.
Alice alicepayment gönderir. Eğer Bob, sonraki 4 saat içinde ödemesini göndermez ise, Alice bobdeposit isteyebilir ki bu da ödemeden %12,5 fazladır, bu sayede Alice iyi bir de bonus kazanmış olur.
Eğer Alice uçları atomik takas protokolünün bu tarafı için istekli olurlarsa şaşırmam.
Bob bobpayment gönderir. Eğer Alice bobpayment harcamaz ise, 2 saaat sonra Bob ödemesini geri isteyebilir ve 4 saat sonra bakiyesini geri alabilir. Bob kendi bakiyesini geri aldıktan sonra Alice kendi ödemesini geri isteyebilir. Bu öyle bir girift şekilde birbirine bağlıdır ki, bir taraf işlemin sonucunu harcarsa diğer tarafın da harcama hakkı oluşur.
Alice bobpayment harcar. Eğer Bob alicepayment harcamazsa, Alice tarafında takas işlemi tamamlanmış olur ve Alice’in ihtiyaç duyduğu başka bir şey yoktur.
Bob uyuyor ve aliceödeme’yi harcamadı, o zaman alicepayment harcayana kadar ona ait değildir. Bu Bob’a bağlıdır, fakat biraz da tehlikelidir, eğer alicepayment harcamadan önce bakiyesini yeniden fonlarsa, Alice kendi ödemesini geri istemesi için gerekli bilgiye erişmiş olur. İki tarafından, takas tamamlanıncaya kadar atomik takas protokolünü işletmesi önemlidir. Eğer 4 saat sonra, Bob hȃlȃ uyuyorsa, o zaman Alice bakiyesini isteyebilir ve mutlu bir kampçı olabilir. Alice, Bob’un bakiyesini harcar, ancak bu ona kendi ödemesini geri istemesi için gerekli bilgiyi vermez, yani Bob uyandığı zaman bunu hȃlȃ yapabilir.
Bob alicepayment harcar. Yukarıdaki gibi, eğer Bob kendi bakiyesini yeniden fonlamazsa, bu kendi kaybı ve tamamen kendi sorumluluğudur. Eğer 4 saat sonra, hȃlȃ yapmadıysa, Alice bakiyesini geri isteyebilir.
Bob kendi bakiyesini yeniden fonlar. Her adımda gördüğünüz gibi, bir şey yapmak durumunda olan taraf onu yapmaya motive edilmiştir ve sona doğru aciliyet daha da artar.
BarterDEX, yaklaşık yüz coin arasında ister yerel coin daemonu ister SPV electrum serverları ile, yukardaki platformlar arası yolu uygular. Bir oturumda tamamlanmayan bir takas, zaman tamamlanana kadar BarterDEX çalışır halde tutulursa tamamlanabilir.
Ucunuzun sağlamlığından, özellikle internet bağlantınızdan emin değilseniz, yüksek tutarlarda trade yapmamanız sizin için en iyisidir.
İnanın veya inanmayın, yukarıdaki atomik takas protokolünü, anahtar değişimleri ve bütün kriptografik onaylamalar ile birlikte yapmak, BarterDEX’in yarı zorluğundan bile azıdır.
Göreceli olarak konuşacak olursak, UTXO’ları özellikle test için yapılmış ve dikkatlice hazırlanmış olan iki test nodu arasında izole bir atomik takas yapmak “kolay”dır. Herhangi bir kişinin herhangi biriyle orderbook ve emir eşlemenin gerçekleşmesi gibi işlemlerle hemen trade’e başlaması tamamen başka bir meseledir. Uçtan uca işlemlerin doğası gereği, başarılı bir takas garanti etmek imkansızdır, ancak başarısız olan bir takas başlatmak sadece birkaç saniyelik bir kayıptır ve bir takası denemenin maliyeti yoktur. Normal trade’de, istediğiniz trade’i yapacağınız garanti edilmez, aynı şekilde BarterDEX’te de bir garanti yoktur.
Atomik Takas Protokolünün Detaylı Açıklaması
Atomik takas protokolünün kapsamını bildiğimize göre biraz da daha detaylı şekilde ne gerektiğine bakalım. Bir atomik takası başlatmak için bile, alice tarafında bir çift, yani dexfee ve aliceödeme oluşturulmalıdır ve bob’dan da bobbakiye ve bobödeme oluşturulmalıdır. BarterDEX bütün bu dört UTXO’nun da atomik takas protokolü başlamadan önce belirlenmesine ihtiyaç duyar.
Burada ilk kullanıcı meselesi gelir. Çoğu kullanıcı UTXO’nun ne demek olduğunu bile bilmez ve çoğu bakiyelerini, satoshi seviyesinde harcayabilecekleri tek bir coin yığını şeklinde görür. Gerçekte ise bitcoinprotokolü belirli değerlerin Harcanmamış İşlem Çıktıları (UTXO) listesini oluşturur ve bir transaction (işlem) yapmak için, çıktıları ödeyebilmek için yeterli miktarda girdi olmalıdır. Herhangi bir fazlalık çıktıya gider (BarterDEX’in, otomatik olarak, hızlıca onay alacak, mevcut BTC txfee’lerini hesaplamasına rağmen txfee’leri şimdilik ihmal edelim).
Kullanıcının hangi UTXO çiftini kullanacağını belirtmesi pratik değildir ve trade pazarlığı esnasında Alice’in Bob’un belirlediği UTXO’ları belirlediğini bilmesi imkansızdır. BarterDEX’in burada yaptığı bir atomik takas pazarlık protokolü şöyledir:
Alice, özel bir Bob’a, kendi UTXO çifti, fiyat ve hacim ile bir “talep” gönderir.
Bob, Alice’in UTXO’larının geçerliliğini onaylayarak “talebi” doğrular ve fiyat kabul edilebilirdir, sonra Bob en uygun bobödeme ve bobbakiye UTXO’larını oluşturmak için en etkin yolu bulmak için bütün kendi UTXO’larını tarar. Sınırlama, Alice’in ödemek istediği fiyat ve hacim ile eşleşmeli ve bakiye ödemeden %12,5 büyük olmalıdır. Eğer bütün bunlar karşılanırsa, Bob, Alice’e “rezerve” bir paket gönderir. Bunu tam zamanında yaparak, Bob bakiye için bağlanan fonları en aza indirir.
Alice, UTXO’ların geçerliliğinden emin olarak Bob’dan gelen “rezerve” paketleri doğrular, fiyat ve hacimler kabul edilebilirdir ve Bob’a “rezerve” ile aynı parametrelere sahip “bağlan” paketi gönderir. Gönderilen “Talep” ile alınan “rezerve” arasında veya bir 10 saniye timeout ile, Alice’in başka bir trade talebinde bulunması engellenir. Bu mevcutta bekleyen atomik takasın doğru şekilde başlaması için önemlidir ve bu engelleme, aynı zamanda, dICO için balina direncinin bir parçasıdır.
Bob “bağlan”ı onaylar ve her şey tamamsa, atomik takas yapmak için yeni bir süreç başlatır.
Alice “bağlan”ı alır ve her şey tamamsa, atomik takas yapmak için yeni bir süreç başlatır.
Alice ile Bob arasında bir “pazarlık” adımı daha vardır ve bu yukarıdaki 5 adımın parçası olabilecekken, sürecin doğası nedeniyle atomik takas protokolünün içinde kalır. Kullanılacak coin onayları da herhangi bir anlaşma olmaması durumunda, atomik takas, hiçbir ödeme gönderilmeden iptal olur. Zarar yok, hatayok.
DEX fee – dexfee
İnsanlar, BarterDEX protokolünün parçası olarak küçük bir dexfee olduğunu fark edecekler. Bu mevcut işlemin 1/777’si kadardır ve spam saldırılarının pratik olmamasını sağlayacak şekilde ayarlanmıştır. Pratik değildir çünkü gerçek para kaybetmesine neden olur. Bu spam engeli olmadan, BarterDEX, protokol seviyesinde, maliyet-etkin DOS saldırılarına açık olabilirdi.
1/777, 0.1287% ye eşittir ve bu da birçok merkezi borsanın, çoğu durumda önemli bir oranın da altındadır. Lütfen dikkat ediniz, merkezi borsalar trade’in iki tarafından da ücret alır, dolayısıyla eğer %0.2 bile ücret alıyor olsalar, esasında bu %0.4 ücrete denk gelir.
Dexfee BarterDEX ağını emniyete almaya yardım eder ve merkezi borsalardan daha düşük bir seviyeye ayarlanmıştır. Protokolde ilk olarak dexfee alındığı için bazı trade’lerin tamamlanmadan başlaması mümkündür. Bu durumda, bu başarısız atomik takaslar için ücretlendirilmiş bir dexfee olacaktır. Proxy DEX her satış ve alış emri için ücret alır, hatta trade hiç yapılmasa bile. Bu Proxy DEX sistemlerinde işlem yapmak için çok büyük bir negatiftir.
Ayrıca izole bir şekilde değerlendirilmemelidir. BarterDEX protokolü istatistiklere dayanır ve istatistiki olarak bazı başlatılan atomik takasların bazıları tamamlanmayacak.
Diyelim ki %15 oranında başarısızlık oldu (bu gerçekte bizim testlerimizde gördüğümüzün bayağı üstünde, başlatılan takasların %95’ten fazlası tamamlandı, en azından bobödeme fazına kadar), yine etkin dexfee maliyeti hȃlȃ %0,15 olacaktır.
Dolayısıyla, eğer tamamlanmayan bir atomik takasa ilişkin dexfee görürseniz, bilin ki istatistiksel sürecin bir parçasıdır. Eğer %0,15’ten fazla dxfee ödediğinizi tespit ederseniz, lütfen bize bildirin, bu beklenen bir durum değil ve kaynağını bulup tamir etmek isteriz.
Bu nedenle gerçekte 1/777 yani %0.1289 olmasına rağmen, dexfee’yi %0,15 olarak belirtmek daha doğrudur.
Ödemeler toplanır ve bir varlık zinciri (assetchain) olan DEX varlık sahiplerine dağıtılır. Her DEX varlık zinciri birimi sahibi, bu dexfee’yi bir kȃr payı olarak alacaktır.
Transaction Onayları
BarterDex, sadece bir veritabanı güncellemeden (veya Proxy DEX için Proxy token bakiyelerini güncellemeden) direkt gerçek coinleri trade ettiği için, iki taraf da rahat edecekleri onay sayısını beklemek durumundadır. Bir zincirdeki ödemeler yapılırsa diğer zincirdekiler yeniden organize edilmeyeceğinden, yapılan trade’in büyüklüğüne göre yeterli onayı almak önemlidir. Bunu aktive etmek için, tüm coinler için kullanılabilen setconfirms denilen bir API çağrısı vardır. Bu bir atomik takas başlatılmadan önce yapılmalıdır, çünkü bir tarafın onay sayısı (numconfirms) gönderilir ve Alice veya Bob’un hangisinin daha yüksek ise o numconfirms kullanılır. Ayrıca bir de maxconfirms değeri vardır, bu da bir tarafın 100 BTC onayı istemesi gibi bir çılgınca durumu engellemek içindir.
Sıfır Transaction Onayları
Bu alanda ekstrem bir mod vardır, bu alanda sıfır onay (zeroconf) ayarlanabilir! Şimdi bunu yapmak, özellikle hızlı blok zamanlı, düşük hashrate’e sahip coinlerde, oldukça risklidir. Ancak, iç testler için veyaarkadaşlar arası işlemlerde, bir atomik takasın baştan sona 13 saniyede tamamlandığını görmek oldukça eğlencelidir.
Fikir şudur, eğer insanlar beklenmeyen blokzinciri hataları durumunda işleri doğru yapmaya anlaşmışlarsa, diğer kişiler diğer tarafa, işlerin doğru şekilde olması için gerekli işlemleri yapacağına güveniyorlarsa, zerconf tradeing açılabilir. Pozitif bir güven ayarlamak için özel bir güven API’si vardr. Eğer negatif ayarlanırsa pubkey kara listelenir.
Gerçek-zamanlı Ölçüler
Emir eşleme sürecinin son bir özelliği ise, eşleme için muhtemel adayların filtre olarak kullanıldığı gerçek zamanlı metriklerdir (RTmetrics). Bütün uçlar küresel istatistikleri stats.log dosyası ile takip ederve bu da her ucun bekleyen takaslar listesini günceller. Bu bilgiyi kullanarak, meşgul olan uçlara daha az öncelik verilir. Ek olarak, Alice, emir defterinde doğru aralıkta UTXO büyüklükleri bulunmayan Bob’laradaha az öncelik verir. Bu kısım oldukça yenidir ve sonraki BarterDEX yinelemelerinde daha da geliştirilip iyileştirilebilir.
Emir Defterinin Etkinliği
Atomik takas detaylarından, emir eşleme sürecine doğru olmak üzere geri yönde çalıştık ve bu da açıklamak üzere etkin emir defteri yayılmasını açıklamayı bıraktı. BarterDEX baz kurun rel kura dönüştürülmesi anlamına gelen bir baz/rel düzeni kullanır. Bir baz/rel almak rel kurunu kullanarak baz kurundan almak demektir, fiyat baz/rel oranında belirtilir.
Bir emir defteri oluşturmak için bir uç fiyat bilgisine sahip olunmalıdır ve her şey pubkey tabanlı olduğu için, bu da bir fiyatın bir pubkey’den geldiği anlamına gelir.
Son olarak özel bir txid/vout (UTXO) gereklidir, fakat tek bir uç yüzlerce UTXO’ya sahip olabilir ve bu da küresel olarak yayılabilmek için oldukça fazla ağ bant genişliği kullanır. BarterDEX, bu durumda, iskeleti her bir baz/rel çifti için bir pubkey/price çiftinden oluşan hiyerarşik bir emir defteri kullanır. baz/rel fiyatında alım yapmak ile rel/baz fiyatında alım yapmak aynı şeydir. Haliyle emir defteri iskeletini doldurmak için tüm ihtiyacınız olan şey bir ucun pubkey ve fiyatını bir baz/rel çifti için yayınlamasıdır. Bununla birlikte, yerel coin daemon çalıştıran uçlar, listunspent ile muhtemel UTXO’ların listesini anında bulabilirler. Ups, Bitcoin uçları adresle tam endekslenmemiştir, haliyle bu uygun bir hizmet değildir ve bir ucun UTXO’larının listesini de yayımlanası gereklidir ve bu da arkaplanda talep üzerine yapılır.
Taklit saldırısını engellemek için kritik bilgiler tamamen imzalanır, dolayısıyla bütün uçlar bir pubkey ile ilişkilendirilmiş akıllı adresleri ve yayımlanan fiyatın geçerli olduğunu doğrulayabilir. Electrum SPV coinler, trade için onaylanmadan önce tüm UTXO’lar için özel bir SPV doğrulaması yapar.
Eğer tüm uçlar tüm UTXO’larını herkese sürekli yayımlarsa, bu durum hızlıca tıkanmaya neden olur. Çoğunlukla BarterDEX sadece pubkey/fiyat çiftlerine dayandığı için, bu kullanışlı orderbook oluşturmakiçin yeterlidir. N adet kur için N*N adet muhtemel orderbook olacağı için, tüm muhtemel orderbook’ların güncellenmesi pratik değildir, bunun yerine, ham veriden istendiği zaman oluşturulur. Orderbook oluşturulması sırasında, orderbook’taki en üst girişlerin hiç listunspent verisi yoksa, bu veri için ağa bir istek yapılır.
Bu süreç, bir trade yapıldığı zaman, bir orderbook’un muhtemel pubkey’ler için listunspent verisini istemesini garantiler. Gerçek emir eşleme süreci orderbook üzerinde, yüksek olasılıkla teklif isteyecek karşı tarafı bulmak için yerel olarak bilinen UTXO’ları yineleyerek tarar. Pratikte, bu işlemin, bütün parametreler doğru şekilde oluştuysa neredeyse anlık olarak yapılabildiğini görüyoruz.
Yukarıdaki BarterDEX’in yüksek seviyeli özetidir ve hâlihazırda aktiftir. Detaylar değişebilir, fakat 29 Ekim 2017 itibariyle BarterDEX özelliklerini tamamlamış ve yaklaşan Monaize dICO’suna çekirdek seviyede hazırdır. Bu dICO muhtemelen geniş sayıda atomik takasın aynı anda başlatılması ile tam bir ateşle deney olacaktır. Mevcut stres testleri beklenen yoğunluğun yönetilebileceğini gösteriyor, tek mesele beklenenin üstünde hacim oluşmasıdır.
BarterDEX evrilmeye devam edecek ve bu yineleme, sıradaki yineleme için düzeltilecek bazı alanların belirlenmesini sağladı. Çeşitli GUI’ler BarterDEX 1.0 API üzerine inşa ediliyor, yeni yinelemeler ile API üzerinde geriye dönük uyumluluk sağlayacaktır.
BarterDEX Whitepaper v2
jl777 30 Ekim, 2017 | v2.0
Çeviri: @komodoturk 2 Mart, 2018
