BarterDEX “Yerel Coinler İçin Atomik Takaslı Desantralize Borsa” (by @komodoturk)

Öncelikle bazı kavramların açıklamaları:

1. pubkey: public key. Private key’e çiftlenen anahtar.  
2. 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.
3. 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. 

4. 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. 
5. Trader: Trade gerçekleştiren taraf(lar).
6. 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.
7. 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.
8. SPV: Simplified Payment Verification (Basitleştirilmiş Ödeme Doğrulama) kısaltmasıdır. Bitcoin Whitepaper’ında Satoshi Nakamoto bu konuyu anlatmıştır.
9. 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.

10. 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.
11. İ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.
12. API: Application Programming Interface kısaltmasıdır. Uygulama programlama arayüzü olarak  çevrilebilir. 
13. 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.
14. 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.

15. 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. 
16. 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. 

17. gettxout: Bir Bitcoin API komutudur. Çağrıldığında bir UTXO’ya ilişkin detayları geri döndürür.
18. RPC: Remote Procedure Calls kısaltmasıdır. Uzaktan Prosedür Çağrıları diye çevrilebilir. 
19. 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.
20. 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.
21. 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.
22. 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.
23. 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.
24. Withdraw: BarterDEX API komutudur. 
25. 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.
26. Privkey: Private key. Coin değerinizi tutan size özel anahtar. Pubkey ile birlikte çifttir.
27. 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