A’dan Z’ye Blockchain Teknolojileri

Kripto Para mimarilarinin temeli aslında Bitcoin’den çok daha öncesine uzanan bir bilgisayar bilimi konseptidir. Satoshi Nakamoto bu alana çok önemli bir katkıda bulunmuştur. Bir çığır açmıştır. Tarihe geçmiştir. Fakat yine de Kripto Paraları Blockchain ismiyle genellemek kavramın aslında orjinal tanımına uymuyor. Kripto Paralar dağıtık ağlardır. Görevleri ise: State Machine Replication.

State Machine

State Machine girdi kabul edip çıktı veren bir makine konseptidir. Girdilere verdiği çıktı cevapları makinenin bulunduğu duruma göre değişir. Bu yüzden ismi durum makinesidir. Aynı durumdaki iki State Machine’e ise aynı girdiler aynı sırada verildiği taktirde çıktıları da aynı olacaktır. Bu makineyi bir kaset çalar gibi de düşünebilirsiniz. 2 kaset çalara aynı kaseti koyup en baştan oynatmaya başlarsanız ikisinden de aynı müziği duyarsınız. Farklı kaset takarsanız farklı müzik duyarsınız. Aynı kaseti taktınız. İkisinde de oynata bastınız ve farklı sesler geldi. Demek ki iki kaset çalar aynı durumda değildi. Birinde şarkının başındayken birinde ortasındaydı. Aynı zamanda kasetten okunanların da doğru sırayla verilmesi gerekir. Kasetin üzerindeki bantlardaki müziği kaset çalar sırayla okursa farklı, kasedi tersten okursa duyulan müzik farklı olacaktır.

Girdi-> Durumu Değerlendirme -> Çıktı

Durumu neye göre değerlendiriyor? Biz makineyi nasıl tasarladıysak ona göre değerlendiriyor. Yani bu bizim çalıştırdığımız yazılım oluyor. Bitcoin yazılımını çalıştırıyorsanız durum değerlemesi yapan makine Bitcoin yazılımı oluyor.

State Machine Replication

State Machine Replication ise örneklemesini yaptığımız mekanızmayı bütün bir dağıtık ağ içerisindeki herkes için aynı şekilde gerçekleştirme çabası. Herkesin aynı durumsal farkındalığa sahip olmasını sağlamaya çalışıyoruz. Örneğin Bitcoin gibi bir ödeme makinesinde, Ali Veli’ye bütün parasını gönderdiyse Ali’nin parasını Veli’ye gönderdiğini herkes kendi local durumuna işlemeli ki, Ali bu parayı tekrar harcamaya çalışırsa Ali’nin harcadığı için artık mevcut olmayan parasını kabul etmesinler. Peki hepsinin aynı local durumda olmasını nasıl sağlayacağız?

Ali sağa sola sahip olduğu parasını birden fazla göndermeye çalışıp duruyor. Hatırlarsak State Machine’ler için girdilerin sırası önemliydi. Bu sebeple Ali’nin yapmaya çalıştığı transferleri hangi sırayla yapmaya çalıştığı konusunda ortak bir noktada buluşmaları gerekiyor. Eğer hepsi farklı sırada bu girdileri alırlarsa varacakları sonuç da farklı olacaktır. Bu da istenmeyen bir durum. Bu sebeple yapılan girdilerin sırası konusunda ortak noktada buluşma işlemine “Consensus” diyoruz. Consensus’un neden girdileri sıralaması gerektiğine dair daha geniş bir okuma için-> tıkla

Makinenin bulunduğu mevcut durumun kaydını tutmak ve sistemdeki girdilerin verisinin elde edilmesi ise State Machine Replication’ın “Data” yükünü oluşturuyor.

Makine’nin mevcut durumunun datasına sahibiz, girdilerin datasına da sahibiz, girdilerin sıralanması konusunda da bir karara vardık diyelim. Geriye mevcut veri ve girdiye bağlı olarak makinenin bir sonraki durumunu ve çıktısını hesaplamak kalıyor. Sistemin bu yüküne ise “Execution” yükü diyoruz.

Consensus-Data-Execution

Verilere sahip ol, girdileri sırala, verilere ve girdi sırasına göre işlemi gerçekleştir. Eğer herkes aynı verilere sahipse ve girdileri aynı sırada işlerse hepsi aynı sonuca varacaktır. Kripto Para’ların tamamının temelde yaptığı şey bu üçlünün gereksinimlerini sağlayarak State Machine Replication yapmaktır.

Scalability Problem

Consensus-Data-Execution herkes bunları uyguluyor. Ağ doğru şekilde çalışıyor güzelce. Fakat Data’ya bütün herkesin sahip olması ve Execute etmesi ağın kapasitesinin artmasında bir dar boğaz oluşturuyor. Ağ biraz hızlandığında veriyi çekmeye, depolamaya veya doğrulamaya kapasitesi yetmeyenler ağdan kopmuş olacaklar. Bu durumda en zayıf halkanın yani standart bir tüketici bilgisayarının rahatça erişip doğrulayabileceği bir kapasiteye sıkışmış oluyoruz. Bu darboğazın sonucu da ciddi bir ölçeklenme sıkıntısı demek.

Light Node — Simple Payment Verification

Satoshi Nakamoto Bitcoin’i oluştururken bu darboğaza yönelik ne sunuyordu peki? Optimistic doğrulama denilebilir aslında. Son kullanıcılar için Simple Payment Verification(SPV) denilen bir doğrulama sistemi bulunur. Bu uygulamaya göre SPV olarak ağı doğrulayan normal kullanıcılar blockların sadece “Header(başlık)”larını depolar. Block içeriğini ise tutmaz. Dürüst blocklar en uzun zinciri(hash yükünü) oluşturduğu müddetçe bu yeterlidir. Bir transferin gerçekleştiğini doğrulamak istediğinde transferin kabul edildiği blockun bu transferi içerip içermediğini sadece o transfer için doğrulayabilir. Bunun bir diğer sebebi de Bitcoin’in blocklara sadece başarılı transferleri ekliyor olması. Peki illegal bir şekilde olmaması gereken bir transferi onaylayan bir block var. Hem de en uzun zincirde. SPV kullanan kullanıcılar DATA’yı depolamıyor, EXECUTION ile doğrulamıyor, o zaman illegal blocku geçerli zannedip kabul edebilir, bunun çözümü nedir?

1. İllegal zinciri oluşturan elemanın hedeflediği kişi siz değilseniz aldığınız transfer yüksek ihtimalle doğru zincirde bir sıkıntı olmadan kabul edilmiştir zaten.
2. Hedef sizseniz ve ağda bu blockun illegal olduğunu görmüş olanlar varsa size bu illegalliğe sebep olan transferi göstererek ve doğrulamanızı isteyerek sizi doğru zincire iletebilirler. Satoshi buna alarm sistemi diyordu.

Mevcut Visa kredi kartı ağı, dünya çapında günde yaklaşık 15 milyon İnternet alışverişini işliyor. Bitcoin, şimdiden ufak bir masraf yapılarak mevcut donanımlarla bundan çok daha fazla ölçeklenebilir. Asla bir ölçeklenme limitine takılmaz. -Satoshi Nakamoto

SPV yöntemiyle sadece Consensus’u takip ettik DATA ve EXECUTION ise gerektiği zaman doğrulanabilir halde durmaya devam ettiler. Böylece kullanıcıya çok az yük binmiş oldu. Ağ bu kullanıcıların limitlerine takılmadan VISA ölçeğinin üzerinde miktarlara kadar ölçeklenebildi. Her şey çok güzel peki bu SPV sistemini daha genele yayabilir miyiz? Herkes SPV çalıştırsın o zaman.

Data Availability Problem

SPV kullanıcılarının illegal işlemler bulunduran en uzun zinciri takip etmeyi bırakmaları için diğer Node’lardan Fraud Proof almaları gerektiğinden bahsettik. Bu Fraud Proof’u elde etmekte zorlanabilirler fakat ya bazı durumlarda bu Proof’u elde etmek imkansızsa?

Diğer Node’ların zincirdeki hataları tespit edebilmeleri için öncelikle Data’ya erişmeleri gerekiyor. Hatırlanacak olursa Data aşaması geçilmeden Execution aşamasına geçemiyorduk. Peki ya bu Data’yı blockları üretenler paylaşmazsa? Block üreticilerinin blocklarını ağ ile paylaşmasındaki çıkarları zincirlerinin üzerinde başkalarının çalışarak zincirlerini uzatarak blocklarının geçerli olma olasılığını arttırmaları. Eğer buna ihtiyaçları yoksa, mesela Bitcoin’de %51 Hash gücünden fazlasına sahiplerse buna ihtiyaçları kalmıyor. SPV kullananlar için Block Header’larını yayınlayıp Block’ların içeriğini kimseyle paylaşmayabilirler. SPV kullananlar zaten Block’un içeriğini indirmiyordu. Şimdi onların yerine de kimse indiremez hale geldi.

Eğer standart prosedürü izliyorsanız, yani bir durumu kabul etmek için Consensus’dan sıralamayı ve Data’yı elde edip sonra Execution aşamasını tamamlıyorsanız Data elinize geçmediği için bu zincirdeki işlemleri kabul etmeyecek ve kurallara bağlı kalmaya devam edeceksiniz. Fakat SPV kullanıyorsanız Data ve Execution konusunda da Consensus’a bağlı kalmış olacaksınız yani Consensus’u oluşturanlara sadece sıralama konusunda değil kararların tamamı noktasında güvenmiş olacaksınız.

Consensus’un çoğunluğunun ele geçmesi zaten Double Spend yapmayı mümkün hale getiriyordu, bu haliyle biraz daha kapsamı genişlemiş oldu sadece. Başka Consensus mekanızmalarında bu böyle değil fakat Bitcoin’de eğer Consensus kontrolü uzun vadeli olarak bir kötü aktörün eline geçtiyse ağı zaten tam anlamıyla kullanılamaz hale getirebilir. Bkz: Link

Dolayısıyla kısa süreli olarak en uzun zincir olmuş bir tarafın SPV kullananlara yönelik bir saldırısı söz konusu. Bu ölçekte bir saldırının hedefinde de büyük işletmelerden bir para çıkışı sağlamaya çalışmak vardır. Tutup da küçük kullanıcının 1000 dolarını almak için 6 tane Bitcoin bloğu kazmaz hiç kimse.

Sık ödeme alan işletmeler bağımsız güvenlik ve hızlı doğrulama için yine de kendi Node’larını çalıştırmalı. -Satoshi Nakamoto

Dolayısıyla SPV sistemini uzunca anlatan Satoshi sonuna üstteki eklemeyi yapmıştır fakat bu günümüzde Bitcoin’in bu sebep bahane edilerek güdük bırakılmasının önüne geçememiştir. Bitcoin bugün neden 7 TPS limitiyle çalışıyor sorusunun cevabı Bitcoin geliştirmelerinin yönetimini sonradan eline alan ekip bu sorunun herkesi etkilediğini iddia ederek SPV kullanımının güvensiz olduğunu ilan etti.

İlk günlerden itibaren Bitcoin’in geliştirmesine katkıda bulunan, Satoshi Nakamoto’nun Bitcoin geliştirmelerini ve client uyarı keyini devrettiği Gavin Andresen bu konuda neler söylemiştir?

Full Node çalıştırmayan %99+’ın bir parçası olmaktan gurur duyuyorum. Başkalarının işlemlerini izleyerek bant genişliğimi boşa harcamam için hiç bir neden yok. -Gavin Andresen

2017'deki bu yorumu 2020'de tekrar gündeme gelince ise şunları söylemiştir:

Bitcoin, Blockstream adlı bir şirket tarafından, önemli geliştiricileri işe alarak ve tartışmaları yoğun bir şekilde sansürleyerek ele geçirildi.

Kimdir bu Blockstream? Bitcoin için transfer çözümleri sunan bir şirket. Borsaların kullandığı Liquid Sidechain, genel kullanıcılara kullandırılmak istenen Lightning Network, patentli Blockstream ürünleridir.

Neden konudan bir miktar uzaklaşarak bunlardan bahsediyorum? Çünkü Satoshi Nakamoto’nun ortaya koyduğu bu sistem üzerine Zero Knowledge teknolojileri gibi ileri seviye kriptografik gelişmeler haricinde manalı bir geliştirme sunulmamıştır. Bitcoin başarmaya çalıştığı konuda gerçekten benzersiz bir teknolojik üründür. Alanında çığır açmıştır. Sonrasında bahsedeceklerimiz ise Bitcoin’in üzerine değil aslında State Machine Replication konseptinin Bitcoin’den önce var olmuş olan klasik kısmının üzerine yapılmış geliştirmelerdir. Çoğunun ana odağı ödemeler değildir.

Turing Complete Execution

Bitcoin’den sonra değinilmesi gereken ilk konu tam kapasite programlanabilirlik sunmak isteyen Ethereum. Ethereum’da genel işleyişte yapılan temel değişiklik programlanabilirliği sağlamak için Bitcoin’in Data yapısında yapılan değişiklik. Consensus-Data-Execution üçlüsünde Data’nın sıralamasının(linearization) Execution için önemli olduğundan bahsetmiştik. Fakat bu önem her sistemde aynı ölçüde yer edinmiyor. Bitcoin’de transferler UTXO yapısı sayesinde birinci sınıf vatandaş. Ethereum’da ise bir veriden ibaret. Bitcoin UTXO yapısı sayesinde yapılan işlemleri birbirinden izole şekilde Execute edebiliyor. Kısaca Bitcoin paralel bir şekilde işleyebiliyorken akıllı kontrat sistemleri seri şekilde işlemeye mahkum. Bitcoin’de UTXO’lar teker teker birbirinden bağımsız doğrulanabilirken Ethereum’da bütün block sırasıyla doğrulanmalı. Bitcoin’de tamamını doğrulamak isteyen “Full Node”lar doğrulama işlemini çok çekirdekli makinalarda paralel şekilde yapabilir. Verileri yine makinelerinde parçalara bölebilir.

Zamanında bilgisayar veya cep telefonu donanımlarıyla ilgilenenler varsa tek çekirdek çok çekirdek geçişi zamanında bu muhabbetler daha sık oluyordu. Çok çekirdek var ama uygulamalar bundan iyi faydalanamıyor gibi söylemler vardı. Burda da öyle bir durum söz konusu, Ethereum tek çekirdekte çalışıyorken Bitcoin çok çekirdekte çalışıyor gibi düşünebilirsiniz. Bitcoin’de SPV doğrulamayı sorun etmezseniz limiti hızlı bir şekilde arttırabilecekken aynı durum akıllı kontrat platformları için geçerli değil. Çok yüksek donanımlar da kullansanız, yükü paralel şekilde dağıtamadığınız sürece limite takılırsınız. Süper Bilgisayar dediğimiz şeyler sadece 100'lerce paralel işlem gücünün birleştirmiş halleridir. Eğer paralel ilerlenebilecek bir işleminiz yoksa manasızdırlar. Seri işleyen bir yapıyı hızlandırmak için de çok hızlı bir son teknoloji işlemci alırsınız en fazla ve bu işlemci rahat çalışsın diye hızlı bir SSD alır işlemleri mümkün olduğunca RAM üzerinden yapmak için de RAM’lere yönelirsiniz vs. Bir işlemciden çekirdek gücü olarak 10 kat daha performanslı bir işlemciye geçmek 20 tane işlemci almaktan daha maliyetlidir çünkü ciddi bir teknolojik sıçrama gerektirir.

Örneğin AVAX ağının sunduğu, son kullanıcının donanımı kullanılarak 4500 TPS ifadesi, UTXO kullanan X Chain’ine aittir. Akıllı kontrat çalıştıran ağı bundan çok çok daha düşük bir TPS’dedir. Bu da üstte anlattığım sebeplerden kaynaklanıyor.

Inter-blockchain Communication (IBC)

Madem programlanabilir blockchainlerin kapasitesi ne yaparsan yap bir sınıra ulaşacak o zaman birden fazla programlanabilir blockchain olacağını kabullenip blockchainler arası bir iletişim standartı oluşturalım.

Bu şekilde bir standart oluşturmak isteyen COSMOS, kendi blockchain’ine geçmek isteyen projelere Tendermint denilen bir altyapı sunuyor . Birbiri ile token alış verişi yapmak isteyen projeler bir diğerinin Validator’lerinin çoğunluğunun dürüst olduğuna inanıyorsa bu bağlantıyı kurmayı seçebilir. 20 blockchain dahi hepsini birbirine bağlamaya kalksan 400 bağlantı kurman gerekecek. Bu da gereksiz yük demek. Bu sebeple Hub and Spoke modeli öneriliyor. Ortada bir merkez ve onunla bağlantı kurmuş olan diğer blockchainler. Cosmos da diğer projelere altyapı konusunda yardımcı olurken kendisi de merkez blockchain olarak bu sistemden fayda sağlamayı planlıyor.

Cosmos’un IBC çözümü için katılan zincirlerde “finality” olmalı. Kısaca blockchain Data’sına bakarak Validator’lerin verdikleri kararlar okunabilmeli. Örneğin Polkadot’da bu şekilde bir finality mekanızması olduğu için istenirse IBC kullandırılabilir. Bu şekilde çalışmayan sistemlere örnek ise “probabilistic” çalışan Bitcoin’in Nakamoto Consensus’u ve Avalanche Consensus. Nakamoto’da en azından yeterli hash gücü üzerinde çalıştıktan sonra SPV çözümü kullanılabiliyor. Avalanche’da bu da yok. Peki bu niye önemli? Çünkü Avalanche’daki Subnet’ler de uygulamaya özel bağımsız blockchain sistemidir. Finality olmadığı için çözüm olarak Subnet’lerin Validator’leri P-Chain üzerinde saklanır. Bir etkileşim durumunda blockchain durumundan bağımsız bir imzalama yürütülür. Cosmos’da blockchain durumunun finalize edilmesi beklenip bu blockchain verisi ile etkileşim sağlanıyordu.

Threshold Signature Scheme

Validator’ler ile direkt etkileşim, özel anahtar birleştirme şemalarıyla(Threshold Signature Scheme — TSS) etkileşime geçilecek zincirler üzerinde gerekli cüzdanlar kurularak da sağlanabiliyor. İlla bir aracıya ihtiyaç yok yani. Bu şekilde TSS kullanarak bağımsız şekilde zincirlerarası çalışan uygulamaya özgü blockchainlere Thorchain ve Synapse örnek verilebilir.

Herkes kendi blockchain’ini kullansın projelerinin temel sorunu da bu zaten. İyi güzel kullansınlar da bunun sana bir faydası yok. Çünkü sana ihtiyaçları yok. Bu bir blockchain ölçekleme çözümü değil aslında. Bunlardan bahsetmeyecektim bu sebepten fakat A’dan Z’ye dediğimiz için sorulacağını tahmin ederek bu kısma bunları ve Chainkey’i ekleme kararı aldım.

Chain-Key

Dfinity, şimdiki ismiyle Internet Computer(ICP) TSS’in biraz daha genelleştirilmiş, güvenlik olarak bir miktar daha taviz verilmiş hali olan Chain-key sistemini kullanıyor. ICP içerisindeki Subnet’ler Chain-key vasıtasıyla “Public Key”(Açık adres) ile temsil edilebilirler. Aynı zamanda http üzerinden de iletişim kurabilirler. Üzerlerinde Website çalıştırılabilir.

ICP geliştiriciler için Validator altyapısını da sağlıyor. Bu sayede akıllı kontrat geliştirir gibi geliştirmelerinizi yapıp halihazırda var olan Validator’lere bunu çalıştırtabiliyorsunuz fakat bu bir güvenlik sorunu oluşturuyor çünkü ağın çok küçük bir kısmı sizin yazılımınızı çalıştıracak Subnet’i oluşturuyor. Kötü niyetlilerse ciddi sıkıntı çıkar. Çıkmasa zaten yazıyı burda bitirir herkes ICP kullansın derdik.

ICP bu güvenlik sorununu çözmek için Data Center Identity(DCID) denilen sistemle Governanve mekanızması yoluyla Validator’lere KYC(kimlik doğrulama) yaptırıyor. Bu noktada bir Permissioned ağa dönmüş oluyor. Türkiye’de çok sevilen Holo’nun çok daha yetkin bir ekip tarafından geliştirilmiş hali gibi düşünülebilir. Orda da benzer şekilde KYC gerekliliği var. KYC istendikten sonra bu sistemlerin hangi derde derman olacağına dair ise bir fikrim yok.

Hardware Scaling

Blockchain’leri yan yana dizerek ölçeklenen ortak bir sistem oluşturmanın sıkıntılarını anladıysak tekil bir programlanabilir Blockchain’in ölçeklenme derdine geri dönelim. Bu konudaki yaklaşımlardan biri EOS projesinin yaklaşımıdır.

EOS dedi ki Validator’ler profesyonel çok büyük şirketlerden oluşacak, devasa donanımlar kullanacağız ve ölçeklenerek 1 milyon TPS gibi değerlere ulaşacağız. Gerçek kullanımda ise 250 TPS’e kadar gelebildi çünkü Paralel işlem yapamıyordu. Paralel Execution sağlamadan sadece donanım güçlendirerek ölçeklenmeye çalışan BSC gibi diğer ağlar için de bu limitler geçerlidir. BSC gibi EVM kullanan projelerin tamamı da Polygon, AVAX C-Chain, Fantom, RSK, Arbitrum vs. kullanım miktarları yeterince artarsa bu limite takılırlar. Ethereum’un mevcut kullandırılan kapasitesi 15 buarada. Sadece teknolojinin kendi maximum kapasitesinde çalışmasını sağlasan dahi büyük bir fark oluşturabiliyorsun ama bu yazılımdaki teknolojik bir gelişmeden kaynaklanmıyor.

UTXO Old Friend

Cardano tarafı programlabilirlikle beraber gelen Paralel işleyememe sorununda suçu Account modelinde buldu. Lanet olsun böyle Data sistemine dedi. Gitti sistemin hepsini UTXO yaptı. Fakat Account modeline geçilmenin de belirli sebepleri vardı. Cardano UTXO kullanınca bu durum programlanabilirliğini ciddi oranda kısıtladı. Çünkü işlemleri birbirinden tamamen izole ederek etkileşim yapmalarını imkansız hale getirmiş oldunuz. Böylece zincir dışı hesaplama kullanmak uygulamalar için şart oldu. Bu ise sorunu sadece kendi uygulama içi etkileşimleri için çözmüş oluyor.

UTXO kullanımı sayesinde SPV sistemini Bitcoin’de olduğu gibi Cardano üzerinde kullanmak mümkün fakat Cardano’da da block boyutları gayet ufak. Normalde standart kullanıcı donanımına göre optimize etsen dahi programlanabilirlikten çok ciddi taviz verdiğin için TPS tarafından kazanman gerekir. Fakat Bitcoin’deki yapay limit gibi bir limit Cardano’da da mevcut. Böylece durduk yere uygulama geliştirmeyi inanılmaz derecede zorlaştırmış fakat buna bağlı gelen ölçeklenme avantajını da kullanmamış olduk.

Verifiable Delay Function (VDF)

Konudan bağımsız kısa bir şekilde bundan da bahsetmek istiyorum çünkü bu konu da paralel ve seri işleme farkına dayanıyor. Verifiable Delay Function dediğimiz yapılar paralel işlenemeyen bir fonksiyonu ağdakilere çalıştırarak onların belirli bir zaman bekleyip beklemediklerini ispatlamalarını sağlıyor. Neden bu bir ispat oluyor? Çünkü paralel şekilde işlenemeyen bu işlemi ne yaparlarsa yapsınlar belirli bir hızın üzerinde tamamlayamıyorlar. Yapılan hesaplama bu sebepten gerçekten belirli bir süre üzerinde zaman harcandığının kanıtı olarak kullanılabiliyor. Bu tabire denk gelirseniz dayandığı prensip bu şekilde.

Transaction Isolation

Örneğin Solana’nın Proof of History’si de VDF’e benzerdir, mantığı burdan gelir. Solana demişken Solana’nın bahsettiğimiz konuya yaklaşımı nedir diye bakarsak cevabı Transaction Isolation. Ne demek yani bu? Solana bir transaction’ın yazabileceği ve okuyabileceği verileri önceden belirtmesini şart koşar. Böylece aynı verilerle işi olmayan işlemleri paralel şekilde işleyebilir. Eğer bir işlem önceden belirtmediği bir veriye erişmeye veya yazmaya çalışırsa işlem orda durur ve başarısız olur. Bu sistemin genel sisteme ciddi avantaj sağlaması için ağda yapılan işlemlerde basit yapıdaki izole işlemlerin çoğunlukta olması lazım.

Solana’da dokunulacak veri noktalarını izole edebildiğin için uygulamaların ölçeklenme durumları da yapılarını ne kadar akıllıca tasarlayabilecekleriyle alakalı. Bu da aslında normalde yaptıklarıyla çok farklı değil. Örneğin Alameda grubu borsalarını ölçeklemeye çalışırken de aynı şekilde hangi işlemleri ne kadar paralel işleyebilirizle uğraşıyordu.

Solana üzerinde bir orderbook borsa kurmak isterseniz de aynı problemlerle uğraşmanız gerekiyor. Bu konudaki tecrübeleri buraya aktarılabilir durumdaydı yani. Solana da gerçekten ne zaman gündeme geldi? FTX kurucusu Sam Alameda Solana üzerinde Serum isimli Orderbook tabanlı merkeziyetsiz borsa kurma kararı alınca.

Bu sistemde şunu anlamak lazım. Rahatlıkla paralel hale getirilebilecek işlemler olsa da beraber paralel işlemenin çok zor olduğu işlemler de mevcut. Yani burda sistemin TPS miktarı işlem tiplerine çok bağlı. Sadece standart token transferiyle veya başka basit işlemlerle ölçümlemeyi yaparsan TPS miktarını inanılmaz yüksek gösterebilirsin. Gerçek kullanımda ise her işlem basit olmayacağı için kazanımlar daha kısıtlı olacaktır. Bir diğer farkı da Cardano kadar işleri zora sokmuyor fakat yine de her işlemin dokunabileceği dataların sınırlanması “Composability” konusunda sıkıntı oluşturuyor. Üzerinde mesai harcamadığım için imkansız demeyeyim fakat YFI’nin Ethereum’da kullandığı komplekslikte Yield Farm stratejilerini Solana’da yaptırmak çok daha zordur.

Bunlara rağmen eğer işlem yaptığınız ortamı parçalara bölüp birbirinden ayırmayacaksanız, tekil bir ortamda işlem yükünü azaltmak için yapabilecekleriniz bunun ötesine çok fazla gidemez. Ethereum’un EVM’sini ve Solana’nın Sealevel’ini tekil olarak karşılaştırırsak bence yapılan geliştirmeler oldukça yerinde olmuş.

Resource Oriented Programming

Solana’daki anlayışa benzer şekilde çalışan bir diğer yapı da Facebook’un projesi Diem’in kullandığı Move VM. Diem projesi de oldukça profesyonel işleyen bir proje ama dahil etmemin sebebi Diem’in kendisinden ziyade bu altyapıyı kullanan Flow projesi.

Solana ekibi de Diem’in Move VM’i ile zamanında bir takım denemeler yapmış. Genel prensip olarak kaynak odaklı programlama yaklaşımı Solana’daki sistemle oldukça benzer duruyor.

Separating Consensus from Compute

Flow’un Execution’a yönelik yaptıkları bununla sınırlı kalmıyor. Execution yapmak için gereken kaslı makineleri ile bekleyenleri standart Consensus Node’larından ayırıyor. İşlemleri direkt yapmayanlar nasıl emin oluyor doğru Execution yapıldığından? Yapılan işlemleri denetleme görevi olan Node’lar da mevcut. Bir hata bulunduğunda ise bir Fraud Proof ile bunu ispatlaması oldukça kolay. Bitcoin’de SPV çalıştıranların zinciri takip etme mantığında bundan bahsetmiştik.

Bunun yanı sıra Flow’da Execution’ı yapan Node’lar yaptıkları Execution sırasındaki değişikler sırasındaki ilerlemelerini checkpointler vasıtasıyla küçük parçalara ayırarak daha rahat doğrulama yapılabilmesini sağlıyorlar.

Bunu (3+3)² işlemiyle gösterebilirim sanırım. Bu işlemi ilk defa yapan kişi iseniz 3+3 işlemini yaparken, bir yandan karesini alma işlemini yapamazsınız. Fakat siz 3+3 işleminin sonucu olan 6'yı checkpoint olarak kaydedip sonucun da 36 olduğunu söyleyip işlemi ikiye ayırırsanız. Bunu doğrulayacak kişi bir tarafta (3+3)’ün 6 olup olmadığını sorgularken diğer tarafta 6²’nin 36 olup olmadığını aynı anda sorgulayabilir. Yani hesaplayan kişi, ikinci işlemin sonucu birinci işlemin sonucuna bağlı olduğu için, işlemleri “seri” olarak yapmak zorundayken, doğrulayan taraf checkpoint sayesinde “paralel” şekilde doğrulayabilir. Bu 2 doğrulama görevini 2 farklı kişiye de dağıtabilirsiniz.

Two-Tier Architecture

Flow’da Execution işinin bağımsız Execution Node’larına verildiğinden bahsetmiştik. Benzer bir durum Algorand’de de mevcut. Flow’dan farklı olarak ise Algorand’de Execution Node’larına aktarılmayan işlemler de mevcut. Kolay şekilde işlenebilen basit transferler ve onlara yakın bir kaç transfer türü Algorand’de Consensus’u işleten Node’lar tarafından direkt işletilir. Geri kalan ise Execution Node’lar tarafından bağımsız şekilde işlenir. Algorand’de zincir üstü işlenen kontratlara Layer 1 kontrat, Execution Node’ları tarafından işlenen işlemlere Layer 2 kontrat denir.

Algorand’in Layer 2 dediği katmanındaki işlemler birbirlerine bağımsız şekilde işlenebilir fakat aslında birbirlerinden gerçek anlamda izole edilmeleri sağlanmamıştır. Bu sebeple bu işlemler Consensus Node’ları tarafından Layer 1'e eklenirken işlemlerin red edilme ihtimali mevcuttur. Bu red edilme ihtimali de akıllı kontratların durumlarını güncelleme ve sonraki işlemleri bu güncellemiş durumuna göre değerlendirmesini imkansız hale gelmektedir. Çünkü durumunu güncelleyebilmek için bu transferin gerçekleşeceğinden emin olmalıdır. Layer 1'e geçtikten sonra red olma ihtimali olan bir transferi kabul edecek şekilde dizayn edersen “ya hep ya hiç” transfer kümeleri oluşturmuş olursun. Bu transferler Layer 1'e gönderildikten sonra bir tanesi fail olursa geri kalan transferleri de işleyemezsin.

İzolasyon yapmadan paralel işlem gerçekleştirmeye kalkmak gerçekten sorunlu bir iş. Silvio Micali’nin bu tasarımdan beklentisi muhtemelen durumları Layer 1'deki basit transfer yapılarında saklayan Layer 2'de ise durumdan bağımsız saf fonksiyonları çalıştıran uygulamalar geliştirilmesi fakat geliştiriciler bu tarz bir geliştirme sürecinin altına girmeye ne kadar istekli bilemiyorum. Bu tarz bir dizaynın yapabilecekleri ne kadar geniş o da muamma.

Karışıklık olmaması için belirteyim burdaki Layer 1 ve Layer 2 Algorand’ın kendi iç isimlendirmesi. Genel kullanımdaki Layer 1 ve Layer 2 anlamından daha farklı bir anlamda kullanılıyor Algorand’de.

Verifiable Random Function

Algorand’ın Consensus ve Execution şekilde alt komiteleri oluşturabilmesinin sebebi manipüle edilmesi zor olan doğrulanabilir rastgeleliğe sahip olmasıdır. Bu yapıyı mümkün kılan “Random” luk,Silvio Micali’nin 2 arkadaşıyla beraber 1999'da Verifiable Random Function(VRF)’yi bulması sayesinde mümkündür. Algorand’in tasarımı konusunda beğenmediğim noktalar olsa da Silvio Micali Cryptography teknolojileri konusunda “efsane” denilebilecek bir geçmişe sahiptir. Micali’nin bulduğu VRF sıradaki başlık olan Sharding’de de örneğin Polkadot tarafından alt komite oluştururken kullanılmaktadır.

Sharding

Algorand’de 2.Tier’deki uygulamalara random Execution komitesi atandığını söyledik. Bu komitelerin işlediği uygulamaların ise birbirinden tam olarak izole edilmediğini söylemiştik. Bu parçaları birbirinden tam anlamıyla izole ettiğimizde bu parçaların her birine Shard deniliyor. Yapılan işleme de Sharding deniyor. Algorand’daki iki katmanlı yapıyı daha izole hala getirdik yani. Sharding yapan sistemlerde iç katmana ve dışardaki izole bölgelere ne denildiği projeden projeye değişiyor ama Ethereum’daki isimlendirmeden devam edersek içteki birinci katman Beacon Chain dıştaki ikinci katmanlar da Shard oldu. Fakat aslında şu haliyle en yakın olduğumuz yapı Zilliqa. Execution konusunda ağı bölüp orda duran Zilliqa çünkü. Ethereum ve Polkadot gibi sistemler için bir aşamadan daha bahsedeceğiz.

İzole Execution alanlarında yapılan hesaplamaların doğruluğunu yine Bitcoin’deki SPV sisteminde bahsettiğim Fraud Proof ile sağlıyoruz. Yanlış hesaplamayı birisi bulursa bildiriyor. Yoksa doğru kabul ediliyor.

Rollup

Bitcoin’den sonra bir anda paralel işlem sıkıntısından dolayı Execution problemine düşme sebebimiz neydi? Programlanabilirlik. O kadar zahmeti çekmişken bari üçbeş bir şeyler yapalım diyerekten yazılımcılar seri işleyen EVM’yi hesap gücü anlamında ölçeklemek için uğraşmaya başladılar. Malum Ethereum tarafı bunu kaplumbağa hızıyla yapıyor. Rollup’larda Sharding için bahsettiğim izolasyon sağlanıyor. Hesaplamaları yapmaları için birileri görevlendiriliyor. Sonrasında da birileri kontrol ediyor. Sıkıntı varsa yine Fraud Proof’larla gösterilerek düzeltiliyor. Bu şekilde çalışan Rollup’lara da Optimistic Rollup deniliyor. Biz her şey yolundaymış gibi Optimistic davranıyoruz. Bir sorun varsa bildiriliyor.

İngilizce’deki tabiriyle Rollup’lar fakir adamın Sharding’i. Rollup’ların birinci sıkıntısı bu izolasyon ağın kendisi tarafından yapılmadığı için çok daha kırılgan garantileri var. Sharding’de kullanılan Fraud Proof sistemlerinde fazla bir gecikme olmadan ve normal işleyiş bozulmadan sistem işleyebilirken Rollup’larda güvenlik sebebiye Fraud Proof’lar için 2 haftaya kadar bir süre ayrılıyor. Bu 2 hafta süre geçene kadar gerçek anlamda bir kesinlik olmuyor işlemlerde. Bu nedenle Optimistic Rollup’lardan çıkış yapmak çok uzun sürüyor.

İkinci sorun ise asıl sistemde değil akıllı kontratlar için yapılmış bir ortamda bunları yaptığın için optimal yazılım çözümlerini kullanamıyorsun. En azından Ethereum tarzı sanal makina kullanan sistemlerde durum böyle. Geliştirme yapılmasını ekstra zorlaştırıyor bu durum. Bu ekstra komplekslik olmasa bile bu karmaşıklıkta bir yazılımda her zaman bir hata bulunabilir. Bu ana ağda olsa bir güncelleme yayınlar çözersin fakat akıllı kontratlar değiştirilemez olmaları için yapılmıştır. Şayet bunu değiştirilebilir hale getirirsen bu sefer güvenlik garantin bu değişikliği yapabilecek komitenin güvenilirliği kadar olur. Eğer güvenliğin harici bir komitenin güvenilirliğine bağlıysa da bunun bu komitenin Validator’u olduğu bağımsız bir zincirin güvenliğine göre bir artısı yoktur. Bu sebeple ben Rollup’ları mantıklı bulmuyorum. Eğer bir ağda izolasyon gerekiyorsa bunu direkt ağın kendisi çözmeli. Akıllı kontrat katmanında yapılacak bir iş değil bu.

State Sharding

Tam izolasyon yapılacaksa ağın kendisinin yaptığı izolasyon daha doğru dedik. Buna da Sharding dedik. Execution konusunda izolasyon yapıldığında projelerin hemen sonrasında söylediği şey de “ Madem Execution’ı böldük parçaladık o zaman bu Execution’ı yapacak olanlar ve doğrulayacak olanların diğer izole alanların Data’sıyla uğraşmasına gerek yok sadece kendi izole alanının Data’sını depolasın.” oluyor.

Bitcoin’de limitledikleri konu da buydu hatırlanırsa. Ne diyorduk? Herkes her şeyin Data’sını tutmasın. SPV sistemini kullansın. Bir sıkıntı olursa Fraud Proof zaten mevcut. Karşı sürülen neydi? Data Availability Problem.

Burda da durum farklı değil. Hem Data’yı herkes tutmasın deyip, hem de ağın güvenliğini sağlayanların çoğunluğunun dürüst olduğuna inanmıyorsan, Data Availability sorununa dönüp dolaşıp gelirsin. Ya ağın güvenliğini sağlayan Node’lara güveneceksin ya da Data sorununu çözmek sorundasın.

Sharding yaptığın zaman böldüğün izole alanlara farklı komiteler de dağıtmak zorunda değilsin aslında. Paralel işlenebilir alan oluşturduktan sonra aynı Node’lar hepsini de işleyebilir zaten ama maksat gereksinimler düşük olsun diye o yola girilince, işlem yükünün önünü kesmişken Data’yı koyver gitsin deseler kendileriyle çelişecekler. Bu sebeple Data Availability Problem projeler için önemli bir gündem.

Data Availability Sampling

Data Availability temelde Data’nın erişilebilir olup olmamasıyla ilgili bir problem. Bir kısım elinde bu Data’yı tutmak zorunda olmak istemiyor, diğer kısım da elinde bu Data’yı tutuyor ve erişilebilir olduğunu iddia ediyor. İlk akla gelen bu iddiayı teste tutmak tabiki. Herkes rastgele Data’nın belirli kısımlarını istesin. Baksınlar data erişilebilir mi değil mi? Bu yöntemdeki ilk göze çarpan sıkıntı Data’nın %99,9'unun erişilebilir olmasına rağmen asıl önemli olan sorunlu %0.1'lik kısmın erişilebilir olmaması ve bu rastgele sample alanların buna denk gelmediği için Data’nın erişilebilir olduğunu düşünmesi.

Erasure Coding

Verinin ufak bir kısmının erişilebilir olmaması problemini çözmek için ilham aldıkları nokta CD’lerdeki Erasure Coding teknolojisi oluyor. Spesifik olarak da genellikle Reed Solomon Erasure Coding. Bunun bulunuşu ise 1960'a dayanıyor.

Erasure Coding’in temelde sağladığı şu aslında. Erişilebilir olmasını istediğin bir Data var diyelim. Bir albüm CD’sinin Data’sı olabilir bu. CD’de bir çizik oldu ve bir kısmı okunamaz hale geldi diyelim. CD çöp mü olacak hemen? Böyle olmamalı.

Erasure Coding ile orjinal veriye bir takım başka veriler de eklenir. Bu eklenmiş verilerle beraber oluşan halini öyle bir şekilde böler ki bu parçalardan hangileri olduğu farketmeksizin belirli bir sayıdaki parça okunabiliyorsa verinin tamamını tekrar oluşturabiliyorsun.

Mesela verileri 99 parçaya böldük diyelim. CD’ye de yazdık. Eğer bu CD’deki 99 parçadan herhangi 34 tanesi okunabilir durumdaysa. Bu 34 tanesinden verinin tamamı tekrar oluşturulabiliyor.

Crypto’daki soruna geri dönelim. Erasure Coding kullanılan bir sistemde eğer verilerin önemli bir kısmı erişilebilir haldeyse. Bu erişilebilir kısımlar kullanılarak saklanan ufak kısım tekrar oluşturulabilir. Eksisi ne denirse bu ufak veriye ulaşabilmek için o veri bloğunun tamamının tekrar oluşturulması gerekiyor.

Bu sistem Ethereum ve Polkadot gibi sistemlerde kullanılarak kendi alt izole bölgelerinin Data bütünlüğü korunmaya ve ölçeklenmeye çalışılıyor. Genel maksat olarak Data Availability servisi sunmaya yönelik olarak ise Polygon Avail ve Celestia gibi projeler de mevcut. Onların da yaptıkları şey temelde bu.

Validity Proofs

Execution komiteleriyle bir üst katman arasındaki doğrulama ilişkisinde hep Fraud Proof’lardan bahsettik. Fraud Proof’lar reaktif sistemler olduğu için görece çok kısa oldukları asıl katman izolasyonlarında dahi bir miktar doğrulama periyodu sebebiyle gecikme gerektirir. Reaktif bir şekilde sorun olduğunda bunu belirtmektense baştan hızlı bir şekilde yapılan Execution’ı doğrulayabilsek daha iyi olurdu. Flow’da gerçekleşmiş seri Execution ufak parçalara bölünerek doğrulayan tarafın işi kolaylaştırılıyordu mesela.

Bunun çok daha gelişmiş bir versiyonu ise Zero Knowledge Cryptography’sinin altyapısından dallanmış bir sistem olan Validity Proof’lar. Bunların Cryptographic altyapıları fazlasıyla karmaşık olduğu için anlatmayı denemeyeceğim bile bu sebepten size biraz “büyülü” bir şeymiş gibi gelebilir. İşin özüne gelirsek hesaplanması meşakkatli olan bu Validity Proof’ları bir defa oluşturduğun zaman, Execution’ı doğrulayacak taraf bu Validity Proof’lar vasıtasıyla yapılan işlemleri anlık bir şekilde doğrulayabiliyor. Matter Labs, Starkware, Polygon Hermez gibi Validity Prooflar üzerinde çalışan ekipler oldukça değerli bu sebeple. Validity Proof’lar ilk ortaya çıktıklarında genel maksat Execution altyapısı olarak kullanılamıyorlardı fakat son 1 yıldır bunu çözmek üzerine çalışıyorlar ve yakın zamanda genel maksat Execution yapabilen örneklerini göreceğiz.

Bu ekiplerin hepsi şuan bu teknolojiyi Rollup olarak geliştiren ekipler. Rollup’ların da çok ideal çözümler olmadığını söyledik ana katmana oranla. Fakat bu bir çelişki değil nasıl Fraud Proof’lar ana ağlarda Sharding örneklerindeki gibi kullanılıyorsa Validity Proof’ları projelerin birinci elden altyapılarına dahil ettiklerini önümüzdeki yıllarda göreceksiniz. Mina’nın kullandığı teknoloji de bunun bir varyasyonudur mesela ve direkt ana blockchainde kullanılıyor. Teknoloji yerine oturduğunda Sharding platformlarında da Fraud Proof’lar yerine Validity Proof’lar kullanıldığını görürüz.

Zero Knowledge Supremacy

Validity Proof’ların birbiri üstüne hesaplanarak akümüle edilmesine Recursive Zero Knowledge Proof deniyor. Mina ile beraber Recursive Zero Knowledge Proof’ların yaygınlaşması da hızlandı ve Mir gibi başka projelerde bunun farklı kullanımlarını göreceğiz. Zcash’de de Halo ile beraber önemli geliştirmeler yaşanıyor. Zero Knowledge teknolojileri zaten gizlilik faydaları sebebiyle oldukça önemliydi. Bu gizlilik tarafındaki kullanımları da Validity Proof olarak kullanımları da önümüzdeki dönemde basit işlemler için olmaktan çıkıp genel maksat Execution için kullanılmaya başlayacak. ZEXE denilen Execution’da hem gizlilik hem de ölçeklenme sağlayan teknolojiyi de, bu geliştirmeyi bizzat geliştiren ekibin liderliğinde Aleo ile göreceğiz.

Crypto piyasası önümüzdeki dönemde “Crypto” isminin hakkını yüksek seviye Cryptography teknolojileriyle verecek gibi duruyor. Zero Knowledge dendiğini duyduğunuz gibi algılarınız açılmalı.

Shard Optimization

Öncelikle yazının gidişatı anlamında ilerledikçe tartışmasız şekilde daha ideale gidiyoruz gibi düşünülmesin. Sharding’in de yanında getirdiği bir takım eksiklikler var. Solana ve Flow gibi tekil yapıları direkt olarak aşağı görmemek lazım. Spektrumun sonu nereye varacak diye bizi götürdüğü yere kadar gidiyoruz.

En son Execution Sharding üstüne Data Sharding ekledik. Nereye vardık? ETH 2.0 ve Polkadot. İzolasyonla ufak Shard’lara böldük. Yazının başındaki Execution üzerine olan tartışmalar bu sefer Shard’lar üzerinde tekrar çıkıyor karşımıza. Bitcoin’deki kadar bir parallelik Shard seviyesine izolasyondan sonra da olmuyor tabiki. 64 veya 100 parçaya bölmekle sınırsız bölünebilirlik aynı şey değil.

Burdan sonrasında yapılacaklar konusunda ise Ethereum’da iş yine başkalarına kalıyor tabiki. Diyorlar ki başkası yapsın. Yani? Yanisi Sharding üstüne Rollup. Ben de yine diyeceğim ki Rollup’lar bu iş için uygun seviye değil. İşinizi başkasına kakalamayın.

Çözümü ise yine bu sorunu daha alt seviyede çözmek. EVM yerine Solana tarzı bir işlem altyapısı veya WebAssembly veya başka bir altyapı kullanılabilir. Hangi seviyede? Shard seviyesinde. Ethereum’da bunu anca çekirdek ekip EVM yerine daha optimize bir ortam kullanarak yapabilir. WebAssembly geçişi konuşuluyordu bir zamanlar fakat şuan rafa kalkmış galiba. Polkadot’da ise Parachain seviyesinde projeler istedikleri değişiklikleri uygulayabiliyorlar. Acala ve Astar’da EVM yanında WebAssembly altyapısı sunularak bir artı sunulmak isteniyor. Bunlar EVM’den kurtularak sağlanan kazançlar tabi. İzolasyon yoluyla ekstra paralellik sağlanmıyor. Onu istiyorsan bu tercihi tekrar Parachain seviyesinde yapacaksın demektir.

Sidenote

Buarada yazının başında Consensus, Data, Execution üçlüsünden bahsettim fakat detaylarda Consensus’a neredeyse hiç değinmedim. Bunun sebebi Satoshi’nin çıkardığı Nakamoto Consensus sonrası, Consensus’un uzun yıllar boyunca ana gündem konusu olması. Bu konudaki uğraşlar POW-POS gecişi, işlem onayı bekleme süresinin kısaltılması, Validator sayısının arttırılabilmesi noktasında farklı şeyler sundu. Şuanki ana gündem olan TPS veya işlem kapasitesi anlamında ise Consensus oldukça önemsiz bir etkendir.

Parallel Execution in Parallel Blockhain

Gidebileceğimiz noktaya kadar gitmeye devam. Her bir Shard’ın özelleştirilebilmesi sebebiyle Polkadot’dan devam ettik. Acala ve Astar gibi projelerde opsiyonel olarak WebAssembly sunulacağını söyledik, bu bir geliştirme. Patract ekibi Parachain çıkarmaktan vazgeçmese tamamen WebAssembly çalıştıracak bir Parachain de olacaktı. Onlar Acala gibi projelere destek olma yoluna gittiler.

Polkadot’un geliştiricisi Parity’nin içinden ayrılan takım üyelerine de sahip olan Gear ekibi ise bunlardan daha sonra işe koyuldu. Gear’in sisteminde iptal olan Patract gibi sadece WebAssembly kullanılabiliyor. Buna ek olarak Parachain içerisinde de ekstra izolasyon yoluyla Parallel’lik sağlanmış. Parachain içerisindeki izole uygulamaların çalışma mantığı itibariyle Parachain’lere benzemesini ekip “Parachain’lerle aynı dili konuşuyorlar” şeklinde yorumluyor.

Gear’i ve Paralel işlem mantığını ise ayrı bir yazıda anlatacağım. Çünkü yazıda da anlattığım bu uzun yolculuğun sonuna gelmişken bu proje ilgimi çekti. Henüz bilinen bir proje değil. Bu sebeple proje ile iletişime geçtim. Gear ile ilgili yakın zamanda önemli şeyler yapmayı planlıyorum. İlk etapta bir inceleme yazısı ve ekip ile bir AMA gündemimde. Takipte olmanız için Gear Türkiye Telegram grubuna girmenizi tavsiye ederim.

Yazıyı da burda bitirelim. Bazı bölümlerde kopukluk varsa bundan da bahsetmiş olalım diyerek sonradan aralara ekleme yaptığımdandır. Yazıda bahsetmediğim tek kategori Filecoin benzeri veri depolamaya yönelik projeler. Zero Knowledge projelerini de biraz kısa kestim fakat onlar ayrı bir derya. Bunlar dışında merak ettiğiniz bir proje varsa muhtemelen yazıdaki kategorilerden birine giriyodur ama farkında değilsinizdir. Yazıda terimler kullandım fakat bir terim kullanacaksam onu ilk defa kullandığım yerde ne olduğunu açıklamaya da çalışıyorum. Anlamadığınız terim varsa buna dikkat ederseniz sıkıntı kalmayacaktır muhtemelen. Yine de sorularınız varsa sorabilirsiniz her zaman. Uzun ve ağır bir yazı oldu fakat muadilini de başka bir yerde veya başka bir dilde bulamazsınız. Bu işe girişmek çok mantıklı bir şey değil çünkü. Muhtemelen ben de bir daha yazmam. Bu sebeple bulmuşken sonuna kadar faydalanmaya bakın.

Gear Türkiye

@orientusprime | Linktree