Opsiyon? On-Chain?

Opsiyon ticareti, geleneksel finansta spot ticaret hacimlerini aşarken, on chain opsiyonların hacmi ve açık ilgisi, on chain spot hacminin önemli ölçüde gerisinde kalmakta ve merkezi bölgelerin hakimiyetinde kalmaktadır.

On Chain Opsiyonlarla İlgili Sorunlar

Kripto varlık çözümlerindeki mevcut seçenekler LP getirileri için çok zararlı olurken, traderlar için de optimumun altında bir deneyim sağladı. Bu durumu aşağıdakilere bağlıyoruz:

• Yanlış fiyatlandırma: Likidite sağlayıcıları, yeterli ücret telafisi olmaksızın bir taraf olarak hareket etmek zorunda bırakılmaktadır. Örneğin, bir opsiyon AMM’si, daha geniş piyasa IV’üne etkin kalibrasyon eksikliği nedeniyle %110'luk bir IV için opsiyon satabilir. Bu durum, LP’ler için belirli bir süre boyunca kayıpların artmasına yol açabilir.

• Maliyet: Mevcut protokollerdeki pahalı işlemler, yatırımcıların işlemlerini gerçekleştirirken ücretlerde ve hızda ek bir engelle karşılaşmasına neden olur.

• **Delta Güveni: **Çoğu AMM opsiyonları collateral varlık ile teminatlandırdığından, collateral varlığa karşı daha fazla risk üstlenmektedir. AMM getirileri için bu deltaya olan güven, piyasa AMM’nin net pozisyonuna karşı hareket ettiğinde bir risk oluşturmaktadır.

Geçmişte bu sorunların çözümü agresif likidite madenciliği, ödüller ve ‘ponzinomics’ olurdu. Ancak bu sürdürülebilir bir çözüm olmaktan uzaktır; IVX’te likidite sağlamak zaman içinde istikrarlı pozitif K&Z tahakkuk ettirmelidir.

IVX’in Çözümü

Arbitrum Üzerine İnşa Etmek

Bu sorunları çözmek için, işlemin gerçekleştirilmesi sırasında uzlaştırma sorunları olmayan, ölçeklenebilir bir blok zinciri üzerine inşa edilmiş bir opsiyon protokolü gerekir. Abitrum üzerine inşa edilen IVX, maliyetleri düşük tutarken ihtiyaç duyduğu yüksek hesaplama verimini sağlar.

Arbitrum Nitro, hızlı blok süreleri ile on chain düşük ücretli trade’i kolaylaştırarak daha makul gecikme süresi ve opsiyon trade’i için daha uygun bir mekan sağlar.

GMX ile Delta-Hedging

IVX AMM, opsiyonların türevleri olduğu destek tokenlerine karşı periyodik olarak risk tahakkuk ettirir. Bu riskler, hedge edilmeden bırakılırsa, tokenler değer kazandıkça veya değer kaybettikçe AMM’nin fon kaybetmesine veya kazanmasına neden olabilir.

GMX’in oracle tabanlı fiyatlandırma modeli sıfır slipajli trade sağladığından, IVX AMM, bu likiditeyi merkezi bir borsadaki bir emir defterinden almak için ödeme yapmadan net delta risklerini ortadan kaldıran marjlı vadeli işlem pozisyonları alabilir.

🐤 https://twitter.com/ivx_fi

🤖 https://discord.gg/ivx

Sui Cüzdan nedir?

Açık kaynaklı Sui Cüzdanı, Sui kullanıcılarına adres oluşturma, Sui ağındaki varlıkları görüntüleme, yönetme ve dApp’lerle etkileşim kurma imkânı sağliyor. Sui Cüzdanı, Sui ekosistemindeki diğer potansiyel cüzdanlar ve uygulamalar için bir referans uygulaması olarak hizmet vermektedir. Bu amaçla, en yeni ve en benzersiz Sui güncellemelerini sergileyecektir. Sui Cüzdan reposunun, Sui ölçekli kullanım durumlarını, Move destekli sahiplik modellerini ve Sui’ye özgü diğer özellikleri desteklemeye başladığında önemli bir ekosistem etkinleştirme aracı olarak işlev göreceğine inanıyoruz.

Sui Cüzdan, geliştirici topluluğundan gelen girdilere göre uyarlanacaktır. Sui Discord’umuza katıldığınızdan ve #genel veya #öneriler kanallarından doğrudan geri bildirim sağladığınızdan emin olun.

Sırada ne var?

Web3'ün gerçek anlamda benimsenmesine giden yol, geliştirici topluluğu ve genel olarak ekosistemin güçlendirilmesinden geçiyor. Sui ekibi, geniş çapta benimsenmeye ulaşmak için en iyi, en yüksek performanslı blok zincirini inşa ediyor — ve en iyi fikirler, uygulamalar ve iş modelleri, topluluktan gelecek.

Sui Cüzdan, ekosistemin etkinleştirilmesi ve eğitimi için bir araçtır ve sadece bir cüzdan olması amaçlanmamıştır. İşbirliğine açığız ve topluluğumuzun neler inşa edeceğini görmeye hevesliyiz. Aslında, bir kripto cüzdanının mevcut tanımları sınırlayıcı ve hızlı kullanıcı benimsemesi ile büyük web2 geçişi için optimize edilmemiş olabilir. Cüzdan üreticileri bir sonraki cüzdan yinelemesini zorlamaya başladıkça, biz de Sui topluluğunun neler hayal edeceğini görmek için sabırsızlanıyoruz.

V0.0.2'deki Özellikler

Hesap oluşturun veya mevcut bir cüzdanı içe aktarın

SUI tokenlerini ve NFT’leri aktarın

NFT mintleyen örnek dApp ile basit cüzdan bağlantısı

Sui Explorer’ın geçmişini görüntüleyin ve doğrulayın

İnsan tarafından okunabilir işlem imzalama

Sui cüzdanı, yalnızca serileştirilmiş bir işlem imzalama talebi gösterip tahmin yürütmenize izin vermek yerine, güvenle imzalayabilmeniz için işlemin içeriğini açıkça gösterir. Daha fazlası için çalışmalar devam ediyor!

💻 https://sui.io/

🐤 https://twitter.com/SuiNetwork

🤖 https://discord.gg/GsJH6WDfZY

Finans, oyun, sanat, sanal dünyalar, sosyal medya ve hatta topluluk hareketleri için yeni fırsatların temelini oluşturan blok zinciri teknolojisi ile internetin üçüncü paradigma değişiminin ortasındayız.

Yakın geçmiş

Geçtiğimiz birkaç yıl içinde kripto, yatırım yapmak, borç almak, borç vermek, sigorta satın almak, türev ürünleri alıp satmak, NFT’leri alıp satmak, oyun ve metaverse dünyalarında para birimi olarak ve birçok Web3 proje topluluğu için yönetişim tokenleri olarak giderek daha fazla kullanılmaktadır.

Bununla birlikte, blok zinciri teknolojisi uzun bir yol kat etmiş olsa da, Web3'ün vaadi, ancak insanlar merkeziyetsiz varlıkların ticaretini yapmak için daha iyi imkanlara sahip olduklarında gerçekleşecektir.

Mevcut gerçeklik

Bireyler ve kurumlar kripto ticareti yaparken ve DeFi’ye geçerken bir dizi zorlukla karşılaşıyor:

• Bölümlenme: Blok zincirleri, varlıkların sanal silolarda sıkışıp kaldığı izole ekosistemlerdir.

• Karmaşıklık: Ağlar ve zincirler arasında kripto ticareti yapmak hala son derece karmaşık;

• Risk: Protokol istismarları artıyor ve her yıl milyarlarca dolar kaybediliyor;

• Maliyetler: Pahalı gaz ücretleri mikro işlemler için büyük bir engeldir;

• Verimsiz: Çoğu kriptodan faydalanılamıyor ve likit olmayan bir varlık olarak sıkışmış durumda bekliyor, çünkü yatırım seçenekleri genellikle çok karmaşık;

• Kontrol: Merkezi borsalardaki kullanıcılar varlıklarının velayetine sahip değildir;

• Belirsizlik: Birçok merkeziyetsiz borsadaki kullanıcılar slipaj, likidite sağlayıcıları için geçici kayıp (impermanent loss), belirsiz işlem zamanlaması, MEV sandwich saldırıları ve limit emirleri için destek eksikliğinden muzdariptir.

Evet, bu sorunların bazılarını çözmek için bazı harika projeler var — ancak tüm sorunları aynı anda ele alan bir proje yok.

Yakın gelecek

Bu zorlukların üstesinden gelmek için ihtiyaç duyulan şey şudur

Hem yeni hem de deneyimli DeFi yatırımcıları için tasarlanmış, kusursuz bir kullanıcı deneyimine sahip, ultra güvenli, sermayeyi verimli kullanan, çok zincirli, merkeziyetsiz, düşük ücretli ve devasa likiditeye erişimi olan bir emir defteri borsası.

Henüz mevcut değil, bu yüzden biz inşa edeceğiz.

Ödün vermeden çok zincirli emir defteri ticareti

Planımız basit: Çok zincirli DeFi evrenine Binance veya Coinbase’e daha çok benzeyen merkezi olmayan bir emir defteri alım satım deneyimi getirerek zaten var olmasını istediğimiz DEX’i inşa ediyoruz.

• Tek adımda çok zincirli alım satımlar — spot alım satım ve türevler için emir defteri modelini kullanan daha hızlı ve basitleştirilmiş bir kullanıcı deneyimi — DYDX’e benzer, ancak çok zincirli;

• Zengin likidite — rekabetçi fiyatlarıyla doldurulan alım ve satım emirleri;

• L2* üzerinde işlem yaparken gaz ücreti olmaması— işlemleri zincir dışına yani Layer2'ye taşıyarak ödeyeceğiniz düşük işlem ücretleridir;

• Garantili güvenlik — ‘zero knowledge’ teknolojisi ile herhangi birinin (ZKEX ekibi bile değil) kötü niyetli davranış tehlikesi neredeyse ortadan kaldırılmıştır;

• Daha iyi sermaye verimliliği— kripto paranızı teminatlandırın ve daha fazla ticaret fırsatı için stabil coin ödünç alın;

• Emanete dayalı olmamak- varlıklarınız üzerindeki kontrolü her zaman elinizde tutarsınız.

*L1 ve L2 arasında para yatırırken veya çekerken hala gaz ücretleri olduğunu unutmayın.

Projemiz ve nasıl dahil olabileceğiniz

Dünyanın dört bir yanından ekip üyeleriyle tez odaklı bir projeyiz. Web3'ün ancak çok zincirli merkezi olmayan dünya kesintisiz, güvenli ve özel olduğunda kritik kütleye ulaşacağına inanıyoruz.

Misyonumuz iddialı ama bir o kadar da basit:

Hem yeni hem de deneyimli DeFi yatırımcıları için sektörün en iyi çok zincirli kripto borsası deneyimini sunmaya çalışıyoruz.

Önümüzdeki haftalarda, ürünümüzün erken bir demosunu denemenize olanak tanıyan devnet’imizi başlatacağız.

Bundan kısa bir süre sonra, kullanıcıları test etmeye ve nihai sürümü iyileştirmek için geri bildirim sağlamaya teşvik eden teşvikli bir testnet olacak.

Discord’daki topluluk etkinliklerine katılın, bizi Twitter’da takip ederek en son güncellemeleri alın ve ZKEX.com adresindeki web sitemizi yer imlerine ekleyin.

- ZKEX ekibi

2018 yılında Ethereum’un proof of stake çözümünün merkezileşme riski üzerine ilk makalemi yazmıştım. O zamanlar bu yazının bir üçlemeye dönüşeceğini tahmin etmemiştim.

“The Staking Problem” başlıklı yazımın önermesi şuydu; önerilen minimum 1.500 Etherlik stake ve %100 kesinti cezalarıyla, yalnızca uzmanlaşmış Staking as a Service şirketlerinin Ethereum doğrulayıcılarını çalıştırma becerisine sahip olacağını ve er ya da geç bu merkezileşen ve küçülen grubun Ethereum’un tarafsızlığından ödün vermeye başlayacağını düşünmüştüm.

Neredeyse iki yıl sonra, 2020 yazında, Eth2'nin mimarisi çok daha iyi tanımlanmış ve kriptografik atılımlar minimum hisseyi 32 Ethere kadar düşürmüştü. Pandemiden kısa bir süre önce serbest çalışmaya başlamıştım ve boş blog sitemi doldurmak için “The Staking Problem (revisited)” adlı bir devam yazısı yazdım.

O sırada ilk müşterimi yeni bulmuştum. Bir yılı aşkın bir süre boyunca Blockdaemon’ın Ethereum 2 çabalarına liderlik etme zevkini tattım ve burada bugüne kadar dünyanın en büyük Ethereum stake dağıtımlarından birini inşa ettik. Ancak bu çaba sırasında, daha önce uyardığım tehlikeye açık duruma istemeden de olsa yol açmadığımızdan emin olmak istiyordum.

Beacon zinciri lansmanından sonra, staking’i daha da merkeziyetsizleştirmek için yazılım geliştirmeye başladım ve bunu tek başıma başarmak için iş dünyası hakkında yeterince bilgi sahibi olmadığımı hemen fark ettim. Ethereum’un merkeziyetsizleştirilmesinin ve protokolleştirilmesinin ekonomisi üzerinde çalışan Collin Myers ile yeniden görüştüm ve birlikte Obol Labs’ı kurduk. Obol Labs, halka açık blok zinciri ağları için PoS altyapısına odaklanan bir araştırma ve yazılım geliştirme ekibidir. Çekirdek ekip şu anda çoklu operatör doğrulaması yoluyla güvene ihtiyacin en aza indirildiği stake’i teşvik eden bir protokol olan Obol Network’ü inşa ediyor. Ağ, her bir doğrulayıcı istemcinin Dağıtılmış Doğrulayıcı Teknolojisi kullanarak temsil ettiği hata noktalarını ortadan kaldırarak Ethereum’un esnekliğini ve merkeziyetsizliğini artırmayı amaçlamaktadır.

Staking sorununu ele alacağız.

Hata Toleranslı Staking

Şu anda, bir doğrulayıcı için güvenli bir şekilde yedekleme sistemi çalıştırmak oldukça zor. Bu büyük ihtimalle çalışmayacak ve doğrulayıcılarınız kesilecek. Boşuna denemeyin. Genellikle olan şey, er ya da geç hem birincil doğrulayıcınızın hem de yedeğinizin aynı anda çevrimiçi olması ve bir şeyi çift imzalamasıdır. Bu, tek bir doğrulayıcı anahtarınızın her iki yerde de çalıştığı ve belirli bir görev için ağın farklı bölümlerine farklı şeyler söyleyen iki mesajı imzaladığı anlamına gelir. Ağ bunu fikir birliğine varma kabiliyetine bir saldırı olarak yorumlar ve bunun için sizi ciddi şekilde cezalandırır.

Aynı özel anahtarı paylaşan ve farklı zamanlarda çalışması amaçlanan iki bağımsız doğrulayıcı sisteme sahip olma modeline Aktif/Pasif yedeklilik denir.

Staking alanında şimdiye kadar verilen en iyi öneri “sadece yedekleme yapmayın, kesintiler önemli değildir” olmuştur. Bu, bir günü trilyonlarca dolarla ölçülecek kadar büyük bir pazar için yeterli bir çözüm değildir. Hataya dayanıklı bir staking sistemine sahip olmamak, her ölçekteki staking operatörü için risk yaratır. Eğer tek başına çalışan bir düğüm operatörüyseniz, 7/24/365 nöbetçi olmanız beklenemez; öte yandan büyük operatörlerin, doğrulayıcı yük devretme süreçleri otomatik değil de manuel ise, kaç nöbetçi mühendise ihtiyaç duyacaklarına karar vermek zorundadır. Bir vardiya sırasında herhangi bir makine kapanırsa önemli değil, ancak 100 düğüm kapanırsa; bir mühendis, hiçbiri tekrar çalışmaya başlamadan ve bir kesintiye neden olmadan hepsini güvenli ve hızlı bir şekilde öncelik belirleyip ve yük devredebilir mi?

Burada doğru olmayan bir şeyler var.

Bundan daha iyisini yapabiliriz. Doğrulayıcı düğümlerdeki teknik arıza noktalarını ortadan kaldırarak, ağ doğrulama ve stake etme modellerinde bir sonraki evrimi mümkün kılacak yeni bir tasarım alanı açabileceğimize inanıyoruz.

İşbirlikçi Staking

Dağıtılmış doğrulayıcıları birlikte çalıştıran dört farklı operatör

Obol’da, Dağıtılmış Doğrulayıcı Teknolojisi adı verilen bir altyapı ilkelini araştırıyor ve geliştiriyoruz. DVT, aynı anda birden fazla makinede ve istemcide çalışan ancak ağa tek bir doğrulayıcı gibi davranan yeni bir doğrulayıcı türü sağlar. Bu, makinelerin bir alt kümesi arızalansa bile doğrulayıcınızın çevrimiçi kalmasına olanak tanır, buna Aktif/Aktif hata toleransı denir. Bunu bir uçaktaki motorlar gibi düşünün, uçağı uçurmak için hepsi birlikte çalışır, ancak biri arızalanırsa uçak mahvolmaz.

United Airlines’ın 231 yolcu ve 10 mürettebat taşıyan UA328 sefer sayılı uçağı, 20 Şubat 2021'de Denver, Colorado, ABD üzerinde Mayday alarmı verdikten sonra sancak motoru yanmış bir şekilde Denver Uluslararası Havalimanı’na dönüyor.

Obol’un misyonu, insanların ağı çalıştırma sorumluluğunu paylaşmalarını sağlamak ve bu sistemi güçlendirmektir. Dağıtılmış bir doğrulayıcı kümesinin parçasıysanız ve makineniz bir gece çalışmazsa, kümenizdeki diğer operatörler arkanızı kollayacaktır. Başka bir zaman bir haftalığına tatile gittiklerinde ve düğümleri senkronize olmadığında onların yerine geçeceksiniz. Düğümleri çalıştırma sorumluluğunu paylaşabilirsek, yeni bir merkeziyetsizlik sınırı açabiliriz.

Tekil doğrulayıcıların yedeği olabilir. Staking firmaları riski ve ödülü paylaşabilir. DeFi protokolleri, stake edilmiş Ether kullanımlarını çeşitlendirebilir. Büyük kurumlar bulut sağlayıcı riskinden korunabilir. Hata toleranslı, dağıtılmış doğrulayıcı teknolojisi oluşturmanın herkese faydası vardır.

Staking Sorunu

Peki, yüksek uygunluğa sahip doğrulayıcılar stake odaklı Oisín’e nasıl yardımcı olur?

İşte benim görüşüm:

Şu anda doğrulayıcınızı sizin için çalıştıran kişi/ekip üzerine büyük bir bahis oynuyorsunuz. Her şeyi doğru yaparlarsa size yılda yüzde birkaç faiz kazandırıyorlar, her şeyi yanlış yaparlarsa hepsini kaybediyorlar.

Merkeziyetsiz stake etme sektörü henüz çok yeni ve topluluk için güvene gereksinimi en aza indirilmiş stake etme yolunun en iyi nasıl yapılacağını henüz çözemedik. Lido gibi projeler riski herkes için bir havuzda toplarken, RocketPool gibi projeler ise riski bireysel havuzlara ayırıyor. Biri girişleri insanlar ve oylarla sağlarken, diğeri girişleri tokenlar ve kilitlerle sağlıyor.

Benim inancım, doğrulayıcı işlemindeki tek hata noktasını ortadan kaldırabilirsek, daha küçük düğüm operatörlerine daha fazla güvenebiliriz. Bir DAO’nun hazinesinin Ether’ini stake etmesi için tek bir üyeye güvenmeyeceğine inanıyorum, ancak bir DAO, ortak hesap verebileceği gibi doğrulayıcıları çalıştırmak için bir grup üyeye de güvenebilir.

Siz ve arkadaşlarınız tek başınıza 32 Ether’e sahip olmayabilirsiniz, ancak birlikte bir grup oluşturarak bir doğrulayıcıda bölünebilir ve hepiniz ödülü paylaşabilirsiniz.

Bir kurum, müşterilerinin Ether’lerini stake etmek için tek bir operatöre güvenmeyebilir, ancak birlikte çalışan bir grup operatöre güvenebilirler.

Eğer riski paylaşabiliyorsak, hisseyi de paylaşabiliriz. Staking sorununu çözmek istiyorsak, Ethereum staking’ini birlikte çalışan insan grupları için güvenli ve karlı hale getirmemiz gerekir.

Sonuçta bu bir koordinasyon teknolojisi.

• Sui Move, güvenli ve verimli akıllı sözleşmeler yazmanız için eksiksiz ve hazırdır

• Sui, Move’u nasıl entegre ettiği konusunda orijinal Diem tasarımını geliştiren ilk blok zinciridir ve bu iyileştirmelerin somut örneklerini paylaşıyoruz.

Giriş

Move, 2018 yılında Libra projesinin ilk günlerinde doğdu — iki Mysten kurucusu (Evan ve ben) aynı zamanda Libra’nın kurucu ekibindeydik. Yeni bir dil yaratmaya karar vermeden önce, Libra’nın ilk ekibi, geliştiricilerin ne yapmak istediğini ve mevcut dillerin nerede yetersiz kaldığını anlamak için mevcut akıllı sözleşme kullanım durumlarını ve dillerini yoğun bir şekilde inceledi. Tespit ettiğimiz temel sorun, akıllı sözleşmelerin tamamen varlıklar ve erişim kontrolü ile ilgili olması, ancak ilk akıllı sözleşme dillerinin her ikisinin de tür/değer temsilinden yoksun olmasıdır. Move hipotezine göre, bu temel kavramlar için birinci sınıf soyutlamalar sağlarsak, hem akıllı sözleşmelerin güvenliğini hem de akıllı sözleşme programcılarının üretkenliğini önemli ölçüde artırabiliriz — eldeki görev için doğru kelime dağarcığına sahip olmak her şeyi değiştirir. Yıllar boyunca Move’un tasarımına ve uygulanmasına çok sayıda kişi katkıda bulundu ve dil, “web3'ün JavaScript’i” olma gibi cesur bir fikri temel alma hedefiyle platformdan bağımsız bir akıllı sözleşme diline dönüştü.

Bugün, Move’un Sui’ye entegrasyonundaki kilometre taşını duyurmaktan heyecan duyuyoruz: Sui Move, gelişmiş araçlarla desteklenen eksiksiz bir özelliktir ve aşağıdakiler de dahil olmak üzere kapsamlı dokümanlara ve örneklere sahiptir:

• Sui Move objeleri ile programlama üzerine bir eğitim serisi

• Sui Move temelleri, tasarım modelleri ve örneklerinden oluşan bir tarif kitabı

• Mysten Move ekibi tarafından oluşturulan kod anlama ve hata tanılama desteği ile geliştirilmiş VSCode eklentisi!

Move derlemeleri, testleri, paket yönetimi, dokümantasyon oluşturma ve Move Prover’ın sui* *CLI ile entegrasyonu

Fungible** **tokenlar, NFT’ler, DeFi ve oyunları içeren bir dizi örnek.

2021'in sonlarına doğru Sui üzerinde çalışmaya başladığımızda, Move’a yeni bir bakış attık ve hangi erken tasarım kararlarının yeterince iyi oturmadığını hem de Move’un Sui’nin benzersiz özelliklerinden yararlanmak için nasıl geliştirilebileceğini düşündük. Daha önce Sui Move’da dil seviyesinde nelerin yeni olduğu hakkında bir yazı yazmıştık, ancak bu farklılıkları ortaya koyma motivasyonunu derinlemesine incelememiştik. Bu yazının geri kalanında, bu sorgulama örnek odaklı bir şekilde ayrıntılı olarak ele alınmaktadır.

Bir Dakika, farklı Move’lar da mı var?

Move platformlar arası, gömülü bir dildir. Çekirdek dilin kendisi çok basittir: yapılar, tamsayılar ve adresler gibi genel kavramlara sahiptir, ancak hesaplar, işlemler, zaman, kriptografi vb. gibi blok zincirine özgü kavramlara sahip değildir. Bu özellikler Move’a entegre blok zinciri platformu tarafından sağlanmalıdır. Daha da önemlisi, bu blok zincirlerinin kendi Move çatallarına ihtiyacı yoktur — her platform aynı Move VM, bytecode doğrulayıcı, derleyici, prover, paket yöneticisi ve CLI’yi kullanır, ancak bu temel bileşenlerin üzerine inşa edilen kod aracılığıyla blok zincirine özgü özellikler ekler.

Diem, Move’a gömülen ilk blok zinciriydi ve sonraki Move tabanlı zincirler (0L, StarCoin ve Aptos dahil) büyük ölçüde Diem tarzı yaklaşımı kullandı. Diem tarzı Move bazı başarılı niteliklere sahip olsa da, hem Diem’in izinli yapısı hem de Diem blok zincirinin uygulama ayrıntıları (özellikle depolama modeli) bazı temel akıllı sözleşme kullanım durumlarının uygulanmasını zorlaştırmaktadır. Özellikle Move ve Diem’in orijinal tasarımları, NFT’lerin popülerlik patlamasından önce ortaya çıkmıştır ve NFT ile ilgili kullanım durumlarının uygulanmasını özellikle zorlaştıran bazı uygunsuzluklara sahiptir.

Bu yazıda, orijinal Diem tarzı Move gömme ile ilgili bir sorunu sergileyen ve Sui Move’da bu sorunu nasıl ele aldığımızı gösteren üç tür örnek üzerinden yürüyeceğiz. Move hakkında temel bir anlayışa sahip olduğunuzu varsayıyoruz, ancak asıl kilit noktaların programlama geçmişi olan herkes tarafından anlaşılabilir olacağını umuyoruz.

Kolay toplu varlık oluşturma

Varlıkları toplu olarak oluşturma ve dağıtma becerisi, hem web3 kullanıcılarını takıma katmak hem de kullanıcıların ilgisini çekmek için son derece önemlidir. Belki de bir Twitch yayıncısı hatıra NFT’leri dağıtmak, bir içerik üreticisi özel bir etkinlik için bilet göndermek veya bir oyun geliştiricisi tüm oyuncularına yeni öğeler dağıtmak istiyordur.

İşte Diem tarzı Move’da bir varlığın toplu basımı için kod yazmaya yönelik (başarısız) bir girişim. Bu kod girdi olarak alıcı adreslerinin bir vektörünü alır, her biri için bir varlık oluşturur ve varlığı aktarmaya çalışır.

struct CoolAsset { id: GUID, creation_date: u64 } has key, storepublic entry fun mass_mint(creator: &signer, recipients: vector<address>) {
  assert!(signer::address_of(creator) == CREATOR, EAuthFail);
  let i = 0;
  while (!vector::is_empty(recipients)) {
    let recipient = vector::pop_back(&mut recipients);
    assert!(exists<Account>(recipient), ENoAccountAtAddress);
    let id = guid::create(creator);
    let creation_date = timestamp::today();
    // error! recipient must be `&signer`, not `address`
    move_to(recipient, CoolAsset { id, creation_date })
}

Diem tarzı Move’da, global depolama (adres, tür adı) çiftleri ile şifrelenir — yani, her adres belirli bir türden en fazla bir varlık depolayabilir. Böylece, move_to(recipient, CoolAsset { ... }* *satırı CoolAsset’i recipientadresi altında depolayarak aktarmaya çalışır.

Ancak, bu kod move_to(recipient, …) satırında derlenemeyecektir. Temel sorun, Diem tarzı Move’da CoolAssettüründe bir değeri A adresine gönderemezsiniz:

1- A olmayan bir adres A’da bir hesap oluşturmak için bir işlem gönderir

2- A’nın sahibi, CoolAsset türündeki nesneleri almayı açıkça tercih etmek için bir işlem gönderir

Bu sadece bir varlık almak için iki işlem demek! İşleri bu şekilde yapma kararı, hesap oluşturmayı dikkatlice kısıtlaması ve depolama sistemindeki sınırlamalar nedeniyle hesapların yüksek miktarda varlık tutmasını önlemesi gereken izinli bir sistem olan Diem için mantıklıydı. Ancak bu, varlık dağıtımını ilk katılım mekanizması olarak kullanmak isteyen ya da genel olarak varlıkların Ethereum ve benzeri blok zincirlerinde olduğu gibi kullanıcılar arasında serbestçe gönderilmesine izin veren açık bir sistem için son derece kısıtlayıcıdır [1].

Şimdi aynı kodu Sui Move’da inceleyelim:

struct CoolAsset { id: VersionedID, creation_date: u64 } has keypublic entry fun mass_mint(recipients: vector<address>, ctx: &mut TxContext) {
  assert!(tx_context::sender(ctx) == CREATOR, EAuthFail);
  let i = 0;
  while (!vector::is_empty(recipients)) {
    let recipient = vector::pop_back(&mut recipients);
    let id = tx_context::new_id(ctx);
    let creation_date = tx_context::epoch(); // Sui epochs are 24 hours
    transfer(CoolAsset { id, creation_date }, recipient)
  }
}

Sui Move’un küresel depolaması nesne kimlikleri tarafından şifrelenir. keyyeteneğine sahip her yapı, küresel olarak benzersiz bir idalanına sahip olması gereken bir “Sui nesnesidir”. Sui Move, kısıtlı move_to yapısını kullanmak yerine, herhangi bir Sui nesnesi üzerinde kullanılabilecek bir transfer ilkeli sunar. Bu ilkel, id’yi global depodaki CoolAsset ile eşleştirir ve değerin recipient’a ait olduğunu belirtmek için meta veri ekler.

mass_mint’in Sui versiyonunun ilginç bir özelliği, diğer tüm işlemlerle (mass_mint’i çağıran diğerleri dahil!) döngü oluşturmasıdır. Sui çalışma zamanı bunu fark edecek ve bu işlevi çağıran işlemleri, konsensusa ihtiyaç duymayan Byzantine “hızlı yolu” üzerinden gönderecektir. Bu tür işlemler hem işlenebilir hem de paralel olarak yürütülebilir! Bu, programcıya ekstra bir is çıkarmaz — sadece yukarıdaki kodu yazar ve çalışma zamanı gerisini halleder.

Bu kodun Diem varyantı için bu durum geçerli değildir — yukarıdaki kod çalışsa bile, hem exists<Account> hem de guid::create çağrıları GUID üreten veya Accountkaynağına dokunan diğer işlemlerle uyuşmazlık yaratacaktır. Bazı durumlarda, uyumsuzluklardan kaçınmak için Diem tarzı Move kodunu yeniden yazmak mümkündür, ancak Diem tarzı Move yazmanın uyumlu yollarının çoğu, paralel yürütmeye ket vuran darboğazlar sorunlarını ortaya çıkarır.

Yerel varlık sahipliği ve transferleri

Diem tarzı Move kodunu gerçekten derlenecek ve çalışacak bir geçici çözümle genişletelim. Bunu yapmanın uyumlu yolu “wraper pattern”dir: Bob, Alice’in adresine bir CoolAsset’i doğrudan move_to yapamayacağı için, Alice’ten önce içinde bir koleksiyon türü (Table) olan bir wrapper türü CoolAssetStoreyayınlayarak CoolAsset’leri almayı “tercih etmesini” isteriz. Alice bunu opt_in fonksiyonunu çağırarak yapabilir. Daha sonra Bob’un CoolAssetStore’undaki bir CoolAsset’i Alice’in CoolAssetStore’una taşımasını sağlayan kodu ekliyoruz.

Bu koda bir başka ayrıntı daha ekleyelim: CoolAsset’lerin aktarılmasına, oluşturulmasının üzerinden en az 30 gün geçmişse izin vereceğiz. Bu tür bir politika, (örneğin) fırsatçıların etkinlik biletlerini satın almasını / karaborsaya düşürmesini engellemek isteyen içerik oluşturucular için önemlidir, böylece gerçek hayranların bunları makul bir fiyata almaları daha kolay olur.

struct CoolAssetStore has key {
  assets: Table<TokenId, CoolAsset>
}public fun opt_in(addr: &signer) {
  move_to(addr, CoolAssetHolder { assets: table::new() }
}public entry fun cool_transfer(
  addr: &signer, recipient: address, id: TokenId
) acquires CoolAssetStore {
  // withdraw
  let sender = signer::address_of(addr);
  assert!(exists<CoolAssetStore>(sender), ETokenStoreNotPublished);
  let sender_assets = &mut borrow_global_mut<CoolAssetStore>(sender).assets; 
  assert!(table::contains(sender_assets, id), ETokenNotFound);
    let asset = table::remove(&sender_assets, id);
  // check that 30 days have elapsed
  assert!(time::today() > asset.creation_date + 30, ECantTransferYet)
    // deposit
    assert!(exists<CoolAssetStore>(recipient), ETokenStoreNotPublished);
  let recipient_assets = &mut borrow_global_mut<CoolAssetStore>(recipient).assets; 
  assert!(table::contains(recipient_assets, id), ETokenIdAlreadyUsed);
  table::add(recipient_assets, asset)
}

Bu kod çalışıyor. Ancak bir varlığı Alice’ten Bob’a aktarmak gibi basit bir amacı gerçekleştirmek için oldukça karmaşık bir yol! Tekrar Sui Move varyantına bakalım:

public entry fun cool_transfer(
  asset: CoolAsset, recipient: address, ctx: &mut TxContext
) {
  assert!(tx_context::epoch(ctx) > asset.creation_date + 30, ECantTransferYet);
  transfer(asset, recipient)
}

Bu kod çok daha kısadır. Burada dikkat edilmesi gereken en önemli şey cool_transfer’in bir entryfonksiyonu olması (yani bir işlem aracılığıyla doğrudan Sui çalışma zamanı tarafından çağrılabilir), ancak girdi olarak CoolAssettüründe bir parametreye sahip olmasıdır. Sui çalışma zamanı yine iş başında! Bir işlem, üzerinde çalışmak istediği nesne kimlikleri kümesini içerir ve Sui çalışma zamanı:

• Kimliklerin nesne değerlerine dönüştürür (yukarıdaki Diem tarzı kodda borrow_global_mut ve table_remove kısımlarına olan ihtiyacı ortadan kaldırır)

• Nesnenin işlemin göndericisine ait olup olmadığını kontrol eder (signer::address_of kısmına + yukarıdaki ilgili koda olan ihtiyacı ortadan kaldırır). Birazdan açıklayacağımız gibi bu kısım özellikle ilginçtir: Sui’de, güvenli nesne sahipliği sahiplik kontrolleri çalışma zamanının bir parçasıdır!

Nesne değerlerinin türlerini, çağrılan cool_transfer işlevinin parametre türlerine göre kontrol eder

Nesne değerlerini ve diğer bağımsız değişkenleri cool_transfer parametrelerine bağlar ve işlevi çağırır

Bu, Sui Move programcısının mantığın “para çekme” kısmının zahmetli kısmını atlamasına ve doğrudan ilginç kısma geçmesine olanak tanır: 30 günlük sona erme politikasını kontrol etmek. Benzer şekilde, “para yatırma” kısmı da yukarıda açıklanan Sui Move transferyapısı ile büyük ölçüde basitleştirilmiştir. Ve son olarak, CoolAssetStoregibi dahili bir koleksiyona sahip bir wrapper türü tanıtmaya gerek yoktur — kimlik endeksli Sui global depolama, bir adresin belirli bir türde rastgele sayıda değer depolamasına olanak tanır.

Belirtilmesi gereken bir diğer fark ise Diem tarzı cool_transfer’in 5 farklı şekilde iptal edilebilmesine (yani başarısız olup transferi tamamlamadan kullanıcıdan gaz ücreti almasına) karşın Sui Move cool_transfer’in sadece 1 şekilde iptal edilebilmesidir: 30 günlük politika ihlal edildiğinde.

Nesne sahipliği kontrollerinin çalışma zamanına yüklenmesi sadece kolaylık açısından değil, güvenlik açısından da büyük bir kazançtır. Bunun çalışma zamanı seviyesinde güvenli bir şekilde uygulanması, bu kontrollerin yapım aşamasında uygulanması (ya da tamamen unutulması!) hatalarını önler.

Son olarak, Sui Move giriş noktası işlev imzasının cool_transfer( asset: CoolAsset, ...) bize işlevin ne yapacağı hakkında ne kadar fazla bilgi verdiğine dikkat edin (daha opak olan Diem tarzı işlev imzasının aksine). Bu fonksiyonun CoolAsset’i transfer etme izni istediğini düşünebiliriz, oysa farklı bir fonksiyon olan f(asset: &mut CoolAsset, ...)* CoolAsset’i yazma (ancak transfer etmeme) izni ister ve g(asset: &CoolAsset, ...) *sadece okuma izni ister.

Bu bilgi doğrudan fonksiyon imzasında mevcut olduğundan (yürütme veya statik analiz gerekmez!), doğrudan cüzdan ve diğer istemci araçları tarafından kullanılabilir. Sui cüzdanında, kullanıcıya iOS/Android tarzı bir izin istemi sağlamak için bu yapılandırılmış işlev imzalarından yararlanan ve aynı zamanda** insan tarafından okunabilir imzalama istekleri **üzerinde çalışıyoruz. Cüzdan şöyle bir şey söyleyebilir: “Bu işlem CoolAsset’inizi okuma, AssetCollection’ınızı yazma ve ConcertTicket’ınızı aktarma izni istiyor. Devam edelim mi?”.

İnsan tarafından okunabilir imzalama talepleri, cüzdan kullanıcılarının etkilerinin ne olabileceğini anlamadan işlemleri körü körüne imzalamak zorunda kaldığı mevcut birçok platformda (Diem tarzı Move! kullananlar da dahil) bulunan büyük bir saldırı vektörünü ele almaktadır. Cüzdan deneyimini daha az tehlikeli hale getirmenin, kripto cüzdanlarının yaygın olarak benimsenmesini teşvik etmek için önemli bir adım olduğunu düşünüyoruz ve Sui Move’u, insan tarafından okunabilir imzalama istekleri gibi özellikleri etkinleştirerek bu hedefi destekleyecek şekilde tasarladık.

Heterojen varlıkların gruplandırılması

Son olarak, farklı türlerdeki varlıkların gruplandırılmasına ilişkin bir örnek ele alalım. Bu oldukça yaygın bir kullanım durumudur: bir programcı farklı türlerdeki NFT’leri bir koleksiyonda gruplamak, bir markette birlikte satılacak öğeleri bir araya getirmek veya mevcut bir öğeye aksesuar eklemek isteyebilir. Somut olarak, aşağıdaki senaryoya sahip olduğumuzu varsayalım:

• Alice bir oyunda kullanılmak üzere bir Characternesnesi tanımladı

• Alice, karakterini daha sonra oluşturulan farklı türlerdeki üçüncü taraf aksesuarlarla süslemek istiyor

• Herkes aksesuar yaratabilmelidir, ancak Characterin sahibi aksesuar ekleyip eklemeyeceğine karar vermelidir.

• Bir Characteraktarıldığında, tüm aksesuarları otomatik olarak aktarılmalıdır.

Bu sefer, Sui Hareket kodu ile başlayalım. Sui çalışma zamanı yerleşik nesne sahipliği özelliğinin başka bir yönünden yararlanacağız: bir nesne başka bir nesne tarafından sahiplenilebilir. Her nesnenin benzersiz bir sahibi vardır, ancak bir ebeveyn nesnenin isteğe bağlı sayıda çocuk nesnesi olabilir. Ebeveyn/çocuk nesne ilişkileri, yukarıda tanıtılan transfer fonksiyonunun bir kardeşi olan transfer_to_object fonksiyonu kullanılarak oluşturulur.

// in the Character module, created by Alice
struct Character has key {
  id: VersionedID,
  favorite_color: u8,
  strength: u64,
  ...
}/// The owner of `c` can choose to add `accessory`
public entry fun accessorize<T: key>(c: &mut Character, accessory: T) {
  transfer_to_object(c, accessory)
}// ... in a module added later by Bob
struct SpecialShirt has key {
  id: VersionedID,
  color: u8
}public entry fun dress(c: &mut Character, s: Shirt) {
  // a special shirt has to be the character's favorite color
  assert!(character::favorite_color(c) == s.color, EBadColor);
  character::accessorize(c, shirt)
}// ... in a  module added later by Clarissa
struct Sword has key {
  id: VersionedID,
  power: u64
}public entry fun equip(c: &mut Character, s: Sword) {
  // a character must be very strong to use a powerful sword
  assert!(character::strength(c) > sword.power * 2, ENotStrongEnough);
  character::accessorize(c, s)
}

Bu kodda, Karakter modülü, bir karakterin sahibinin alt nesne olarak rastgele bir türe sahip bir accessorizenesnesi eklemesine olanak tanıyan bir aksesuar işlevi içerir. Bu, Bob ve Clarissa’nın Alice tarafından öngörülmeyen farklı niteliklere ve işlevselliğe sahip kendi aksesuar türlerini oluşturmalarına, ancak Alice’in hâlihazırda yaptıklarının üzerine ekleme yapmalarına olanak tanır. Örneğin, Bob’un gömleği yalnızca karakterin en sevdiği renkse giyilebilir ve Clarissa’nın kılıcı yalnızca karakter onu kullanabilecek kadar güçlüyse kullanılabilir.

Diem tarzı Move’da bu tür bir senaryoyu uygulamak mümkün değildir. İşte yetersiz kalan birkaç uygulama stratejisi denemesi:

// attempt 1
struct Character {
  // won't work because every Accessory would need to be the same type + have
  // the same fields. There is no subtyping in Move.
  // Bob's shirt needs a color, and Clarissa's sword needs power--no standard
  // representation of Accessory can anticipate everything devs will want to
  // create
  accessories: vector<Accessory>
}// attempt 2
struct Character {
  // perhaps Alice anticipates the need for a Sword and a Shirt up front...
  sword: Option<Sword>,
  shirt: Option<Shirt>
  // ...but what happens when Daniel comes along later and wants to add Pants?
}// attempt 3
// Does not support accessory compositions. For example: how do we represent a 
// Character with Pants and a Shirt, but no Sword?
struct Shirt { c: Character }
struct Sword { s: Shirt }
struct Pants { s: Sword }

Diem tarzı Move’da temel sorunlar vardır:

• Sadece homojen koleksiyonlar desteklenir (ilk denemenin gösterdiği gibi), ancak aksesuarlar temelde heterojendir

• Nesneler arasındaki ilişkiler yalnızca “wrapping” (yani bir nesneyi başka bir nesnenin içinde saklama) yoluyla oluşturulabilir; ancak wraplanacak nesneler kümesi önceden tanımlanmalı (ikinci girişimde olduğu gibi) veya aksesuar bileşimini desteklemeyen geçici bir şekilde eklenmelidir (üçüncü girişimde olduğu gibi)

Sonuç

Sui, Move’u kullanma biçimiyle orijinal Diem tasarımından önemli ölçüde farklılaşan ilk platformdur. Move’dan ve platformun benzersiz özelliklerinden tam olarak yararlanan yerleştirmeler tasarlamak, hem Move dilini hem de altta yatan blok zincirinin yeteneklerini derinlemesine anlamayı gerektiren hem bir sanat hem de bir bilimdir. Sui Move’un kaydettiği ilerlemeler ve sağlayacağı yeni kullanım alanları konusunda gerçekten heyecanlıyız!

[1] Diem tarzı Move’un “belirli bir türden bir varlık almak için kabul edip onaylamanız gerekir” politikası lehine yapılan bir diğer argüman da bunun spam önleme için iyi bir mekanizma olduğudur. Ancak biz spam önlemenin uygulama katmanına ait olduğunu düşünüyoruz. Kullanıcılardan bir varlığı almayı kabul etmeleri için gerçek paraya mal olan işlemler göndermelerini istemek yerine, spam, zengin kullanıcı tanımlı politikalar ve otomatik spam filtrelerinin yardımıyla (örneğin) cüzdan düzeyinde kolayca ele alınabilir.

• Sui Website — https://sui.io/

• Sui Twitter — https://twitter.com/SuiNetwork

• Sui Discord — https://discord.gg/sui

Alternatif Sanal Makineler Ethereum’un Ölçeklenmesini Sağlamak Acısından Çok Önemlidir

Yeni L1'lerin giderek daha popüler hale geldiği bir ortamda var olmasına rağmen, Ethereum hala web3 alanında birçok yönden lider konumdadır. Büyük bir geliştirici ve son kullanıcı ekosistemine, konsensus ve veri kullanılabilirliği katmanında ölçeklenebilirliğe yönelik güçlü bir yol haritasına ve muazzam miktarda likiditeye sahiptir.

Ethereum üzerine inşa edilen çok sayıda rollup ve L2 ölçeklendirme çözümünün de gösterdiği gibi, mevcut Ethereum ekosistemi içinde inşa edilerek elde edilecek şüphesiz çok fazla değer var.

Ancak aynı zamanda, EVM ve Solidity’nin daha az önemli hale geldiğine dair artan bir görüş da mevcut.

EVM uyumluluğu, Ethereum üzerine inşa edilenler de dahil olmak üzere yeni blok zincirleri söz konusu olduğunda artık ya hep ya hiç özelliğine sahip değildir.

Fırsat

Şu anda, ölçeklenebilirliğin önündeki ana engel işlem yürütme hızı değildir; bundan ziyade, konsensus ve veri kullanılabilirliği katmanının destekleyebileceği sınırlı bant genişliğidir. Bu ortamda, EVM’nin yavaş işlem yürütme yetenekleri “yeterince iyi”, çünkü hala Ethereum’un sağlayabileceği bant genişliğini geride bırakıyorlar.

Bununla birlikte, Ethereum, proto-danksharding’in yakın gelecekte ve sharding’in 2023'te sürülmesi planlanan, konsensüs ve veri kullanılabilirliği katmanındaki üst düzey ölçeklenebilirlik yolunda ilerliyor. Ufukta temel katman ölçeklenebilirliği göründüğünden, blok alanı artık temel kısıtlama olmayacaktır. Bir sonraki darboğaz, hesaplama olacak: yürütme katmanlarının işlemleri ne kadar hızlı işleyebileceği.

Bu, gelecekte nispeten yavaş ve hesaplama açısından maliyetli EVM, konsensüs ve veri kullanılabilirliği katmanındaki genişleyen bant genişliği arzına ayak uydurmayacaktır.

EVM, Ethereum blok zincirinin orijinal versiyonu dikkate alındığında, yeterli bir performans sağlayacak şekilde tasarlanmıştır. Her ikisi de ilk sürümlerinden bu yana iyileştirmeler görmüş olsa da, EVM tarafındaki hatırı sayılır ilerlemelerle, geriye dönük uyumluluğu sürdürme ihtiyacı nedeniyle sürekli olarak kısıtlanmıştır.

Ethereum temel katmanında bant genişliğini artırarak eklenen değeri optimum düzeye çıkarmak için, L2'lerin yürütme katmanında daha performanslı VM’ler oluşturarak ve dağıtarak bu ölçeklenebilirlik iyileştirmelerini eşleştirmeleri gerekecektir.

Bu yeni paradigma, yürütme katmanlarının EVM’nin ötesine geçerek Ethereum için gerçek ölçeklenebilirliği takip etmeleri için bir fırsat (ve bir meydan okuma) sunmaktadır.

Çözüm

Fuel tam da bu amaç için tasarlandı: EVM’yi aşarak Ethereum’u ölçeklendirmek.

Mevcut L2'ler ve rollup’lar öncelikle monolitik blok zinciri yığınları için tasarlanmıştır, yani genellikle büyük miktarlarda L1 bant genişliği potansiyeli için optimize edilmemişlerdir. Fuel, bu potansiye ulaşmak için benzersiz bir şekilde yapılandırılmıştır.

Fuel gibi modüler yürütme katmanları, yeni ve geliştirilmiş VM tasarım ilkelerini benimseyerek, Ethereum’un ölçeklendirilmesine doğrudan katkıda bulunurken, verimli ve ölçeklenebilir hesaplama, üstün geliştirici deneyimi ve maksimum güvenlik için özel olarak optimize edilebilir.

Fuel Ethereum’un Ölçeklendirilmesine Nasıl Yardımcı Olacak?

Tüm bunlar ortaya konduktan sonra, Fuel Ethereum’un ölçeklenmesine nasıl yardımcı olacak? Bunun için bir dizi faktör vardır:

♦️ Ethereum’da Geliştirme

Fuel için mevcut yol haritası Ethereum ana ağında geliştirilmeyi içermektedir. Beta-2 test ağı, Ethereum’un Goerli test ağına bir köprü ile zaten bağlandı ve 2023 için tam bir ana ağ uygulaması planlanıyor.

🛣️ Ethereum Yol Haritası ile Uyum

Ethereum çekirdek geliştirici topluluğu, rollup merkezli bir Ethereum’a doğru ilerlediğini açıkça belirtmiştir. Bu yol haritasının bir parçası olarak Vitalik, “Ethereum temel katman ölçeklendirmesinin [öncelikle] zincir üzerindeki hesaplamanın verimliliğine değil, veri bloklarının ne kadar tutabileceğine odaklanacağını” belirtmiştir.

Başka bir deyişle, Ethereum’un ölçeklendirilme çabaları, modüler yürütme katmanları için bant genişliği sağlamaya odaklanırken, işlem yürütme hızında iyileştirmeler yapmak için de bu katmanlara güveniyor. Bu nedenle Fuel, Ethereum’un ölçeklendirme yol haritasını desteklemek için yürütme katmanında hızlı ve verimli hesaplamalar sağlamaya odaklanmıştır.

🔐 FuelVM: EVM içinde Kanıtlanabilir Sahtecilik

FuelVM komut seti, EVM içinde hem etkileyici hem de sahtekarlığa karşı kanıtlanabilir olacak şekilde özel olarak tasarlanmıştır. Başka bir deyişle Fuel, Ethereum’un bir konsensus katmanı olarak kullanılmasını desteklemek amacıyla tasarlanmıştır.

⛓️ Geliştiricileri Ethereum Ekosistemine Getiriyor

Fuel, geliştirici deneyimi ön planda tutularak tasarlanmıştır ve Sway dili şimdiden önemli bir ilgi görmeye başlamıştır. Fuel, geliştiricilerin sevdiği Rust tabanlı bir DSL ve cok yönlü araçlar oluşturarak çok sayıda yeni geliştiriciyi ekosisteme çekecek şekilde geliştirilmiştir.

Buna ek olarak FuelVM’in tasarımı, EVM’de (orderbook DEX’leri gibi) mümkün olmayan yeni kullanım durumlarını mümkün kılmaktadır. Daha fazla özellik ve daha iyi geliştirici deneyimi, daha fazla projeye ve daha çok yönlü kullanım olanaklarına yol açıp ve daha fazla son kullanıcıya ulaşmayı sağlayacaktır.

Fuel, iki ağ arasında güvene minimum ihtiyaç duyan bir köprü ile Ethereum üzerinde konuşlandırılacağından, bu geliştiriciler ve kullanıcılar Ethereum’un büyümesine doğrudan katkıda bulunacaktır.

Fuel: Her Şey Dahil Ethereum Ölçeklendirmesi

Ethereum’un modüler bir yol haritasına olan bağlılığı, yürütme katmanında hesaplamayı daha ölçeklenebilir ve verimli hale getirmenin ve daha ölçeklenebilir bir Ethereum ekosistemi oluşturmanın bir sonraki adımı olduğu anlamına gelir. Alternatif sanal makineler bu bulmacanın çok önemli bir parçasıdır ve Fuel bu konuda öncülük etmektedir.

Fuel, en hızlı modüler yürütme katmanını oluşturarak Ethereum’a maksimum güvenlik ve en yüksek esneklikte iş hacmi getiriyor.

Yengeç Stratejisi (Yığın USDC Stratejisi)

• Ödeme Profili: Baş aşağı gülümseme 🙃 (yani tepe ve tepenin üstündeyken maksimum USD’yi biriktirirsiniz)

• Gelir: USD getirileri, Long Squeeth sahipleri tarafından ödenen günlük primden gelir

• Maksimum Kazanç: Sınırsız

• Maksimum Kayıp: Sınırlı (yatırılan miktar)

• Likidasyon: Yengeç stratejisi pozisyonlarının likide edilmesi mümkün olsa da, otomatik yeniden dengelemeler (MWF) ve %20 ETH fiyat hareketleri için fiyat bazlı yeniden dengelemeler nedeniyle bu oldukça düşük olasılıklıdır.

Yengeç için İdeal Piyasa Koşulları

Yengeç Stratejisi, ETH fiyatının düşük volatilite dönemleriye nispeten istikrarlı bir aralıkta dalgalandığı yatay piyasa koşulları (yengeçler yürürken yan yan hareket ederler, anladınız mı?!) için idealdir. Daha spesifik olarak, Yengeç Stratejisi, Squeeth’in gerçekleşen volatilitesinin Squeeth’in belirttiği volatiliteden daha az olduğu dönemlerde en iyisini yapar.

Yengeç Stratejisi, ETH fiyatından etkilenmeyecek bir pozisyon oluşturmak için kullanıcı USDC mevduatlarını otomatik olarak yönetir (yaklaşık delta 0).

Yengeç stratejisi USD cinsinden karlı olmayı amaçlamaktadır. Strateji, getirilerin hızla azaldığı yield farming gibi DeFi yöntemlerine kıyasla sürdürülebilir yöntemlerle (oSQTH satarak) getiri elde eder. Yengeç = gerçek getiri.

Dikkat Edilmesi Gereken Hususlar:

Mevcut Yengeç Kâr Eşiği (Fiyat Bantları):

• Yengeç Stratejisine para yatırmadan önce dikkat edilmesi gereken en önemli husus, Yengeç’in karlılık eşiğidir (fiyat bantları). Fiyat bantları dar olduğunda Yengeç Stratejisine para yatırırsanız ve daha sonra fiyat bantları geniş olduğunda geri çekilirseniz, Squeeth’i ucuzken etkin bir şekilde satıyor ve pahalı olduğunda geri satın alıyorsunuz demektir. Düşük satıp yüksek almak iyi bir strateji değildir!

• Yengeç Stratejisi kârlılık eşiği, yeniden dengelemeler arasında kârlı bir dönemle sonuçlanacak ETH fiyat aralığını gösterir.

• Kâr eşiği, Squeeth’in mevcut Zımni Volatilitesine (primler) dayanmaktadır. ETH bir sonraki yeniden dengelemeden (MWF) önce her iki yönde de yaklaşık olarak kâr eşiğinden daha fazla hareket ederse Yengeç Stratejisi kârsız olacaktır

Fiyat Etkisi + Slipaj

Negatif fiyat etkisi ve slipaj, bir kulla niçinin bir işlem yaptığında ve fiyat beklenenden daha yüksek veya daha düşük olduğunda (hem alım hem de satım için) gerçekleşir. Olumsuz fiyat etkisi ve slipaj ile mücadele etmek için Opyn, kullanıcıların daha iyi fiyatlandırma ve önemli ölçüde daha az slipaj ile yengeç içine BÜYÜK para yatırmalarını sağlayan bir mekanizma olan Jumbo Crab’ı başlattı!

Risk:

Yengeç Stratejisi bakiyeleriniz için en büyük iki performans riski şunlardır:

• Fiyat bantları dar olduğunda Yengeç Stratejisine para yatırırsanız ve daha sonra fiyat bantları geniş olduğunda geri çekilirseniz

• ETH, yeniden dengelemeler arasında her iki yönde de yaklaşık olarak kar eşiğinden (fiyat bantları) daha fazla hareket ederse.

• Yengeç Stratejisi bakiyeleri likidite edilebilirken, zamana dayalı veya ETH fiyat değişiklikleri eşiğinde otomatik yeniden dengeleme, bir likidasyonun gerçekleşmesini önlemeye yardımcı olur.

Crab’a bakiye yatırmak için şu adrese gidin: https://go.squeeth.com/BestCrab

Discord: https://discord.gg/opyn

Twitter: https://twitter.com/opyn_

Squeeth: https://squeeth.opyn.co/

Bugün, en hızlı modüler işletim katmanını tanıtıyoruz: Fuel, blockchain ölçeklenebilirlik hikayesine yeni bir bölüm ekliyor.

Sorun: L2'ler Ölçeklenebilirlik Krizini Tek Başına Çözemez

L2'ler Ethereum ekosistemine erişim için bir maliyet azaltma marjı açmış olsa da, toplam verim artışı en iyi ihtimalle vasatın üstü olmuştur (hem iyimser hem de ZK yaklaşımlarıyla). Ve Ethereum’da trafiğin yüksek olduğu zamanlarda, L2'ler maliyetleri düşük tutmakta başarısız olmuş ve genellikle bu, işlem başına birkaç dolara yükselmiştir.

Bir topluluk olarak, blok zinciri teknolojisine gerçek anlamda küresel erişim sağlamak istiyorsak, ücretlerde ufak miktarda bir düşüşle yetinemeyiz. Etkili bir değişime ihtiyacımız var. Sadece israfı ve verimsizliği azaltmakla kalmayan, aynı zamanda blok zinciri alanında daha önce hiç görülmemiş yeni kullanım alanları açan bir değişim.

Modüler Yürütme Katmanı nedir?

Katman-1 (L1) blok zinciri mimarilerinde süregelen muazzam bir değişim var. Konsensüs, veri kullanılabilirliği ve yürütmenin birbirine sıkı sıkıya bağlı olduğu monolitik bir tasarımdan (örneğin bugünün Ethereum’u), yürütmenin veri kullanılabilirliği ve konsensüsten ayrıldığı modüler bir geleceğe doğru ilerliyoruz (örneğin yarının ETH2'si veya Celestia’sı). Bu ayrım, temel katmanda uzmanlaşmaya olanak tanıyarak bant genişliği kapasitesinde önemli bir artış sağlar.

Fuel, bu ek bant genişliğinden başka hiçbir ölçeklenebilirlik sisteminin yapamayacağı şekilde yararlanmak için özel olarak tasarlanmıştır. Fuel, modüler blok zinciri yığını için en hızlı yürütme katmanıdır ve en yüksek güvenliği ve esnek verimi sağlar. Buradaki “esnek” kelimesi önemlidir, çünkü bu sadece basit transferler değil, aynı zamanda Ethereum tarzı birlikte çalışabilir Turing-complete akıllı sözleşmeler anlamına da gelir.

Fuel, modüler bir yürütme katmanını şu şekilde tanımlamaktadır: modüler blok zinciri yığını için tasarlanmış doğrulanabilir bir hesaplama sistemi.

Daha somut bir ifadeyle, veri kullanılabilirliği için modüler bir blok zincirinden yararlanan sahte veya geçerliliği kanıtlanabilir bir blok zinciri (veya başka bir hesaplama sistemi).

Fuel, yürütmeyi mümkün olduğunca verimli hale getirme konusunda uzmanlaşmıştır. Bu, kısıtlı bant genişliği gibi monolitik sorunlar için optimize edilmiş olan ve bugüne kadar konuşlandırılmış olan rollup’ların aksine bir durumdur. Ethereum büyüdükçe, uyum sağlamayan projeler, kısıtlı bir hesaplama tasarım alanının sonuçlarına katlanmaya devam edecektir. Şimdi modüler yürütme zamanı.

En Yüksek Güvenlik ve Esnek Verimlilik. Nasıl?

Fuel’in teknoloji yığınının üç temel ayağı vardır:

• Paralel işlem yürütme

• Fuel Sanal Makinesi (FuelVM)

• Üstün bir geliştirici deneyimi (Sway ve Forc ile)

İlk olarak Fuel, UTXO modeli şeklinde sıkı halde erişim listeleri kullanarak işlemleri paralel olarak yürütme yeteneği sayesinde benzersiz bir işlem kapasitesi sunar. Bu, Fuel’in CPU’nuzun tek iş parçacıklı blok zincirlerinde genellikle boşta olan çok daha fazla iş parçacığını ve çekirdeğini kullanmasını sağlar. Sonuç olarak Fuel, tek iş parçacıklı benzerlerine kıyasla çok daha fazla işlem, konum erişimi ve işlemsel verim sağlayabilir.

İkinci olarak FuelVM, geleneksel blok zinciri sanal makine mimarilerinin savurgan işlemlerini azaltmak ve geliştiriciler için potansiyel tasarım alanını büyük ölçüde artırmak üzere tasarlanmıştır. Tasarım, geçmişin hatalarından ve yıllarca süren üretim blok zincirlerinden elde edilen anlamlardan öğreniyor. Artık geliştiriciler, EVM’nin kısıtlamaları göz önüne alındığında başarabileceklerinin çok ötesine geçebilirler.

Üçüncüsü ama en önemlisi: Fuel, Sway adı verilen alana özgü kendi dilimizi ve Forc (Fuel Orchestrator) adı verilen destekleyici bir araç zinciri ile güçlü ve şık bir geliştirici deneyimi sunar. Geliştirme ortamımız Solidity gibi akıllı sözleşme dillerinin avantajlarını korurken, Rust araç ekosisteminde ortaya konan paradigmaları da benimsiyor. Artık geliştiriciler, sanal makineden CLI’ye kadar her bileşenin uyum içinde çalıştığı tamamen dikey olarak entegre bir deneyime sahip olabilirler.

SwaySwap, Fuel üzerinde Uniswap benzeri bir takas

Otonom Geleceğin Motorunu İnşa Etmek.

Tüm bireylerin ve grupların gerçekten doğrulanabilir otonom sistemler yaratma ve bunlardan yararlanma erişimine sahip olduğu otonom bir gelecek öngörüyoruz. Bu sistemler yaratıcılarından bağımsız olarak çalışacak ve yeni nesil insan koordinasyonu ve işbirliğine güç verecektir.

Otonom gelecekte, karmaşık kooperatif ve finansal blok zinciri altyapısı inşa edilebilir ve nihayetinde buna güvenilebilir. Bu yeni altyapı, muazzam miktarda gücün, değer sağlamayan rant peşindeki aracılardan, değer sağlayan kişi ve gruplara kayabileceği anlamına geliyor.

Fuel’i bu otonom geleceğin motoru olarak görüyoruz. Fuel üzerine inşa etmek, tekellerin kısıtlamalarından kurtulmak anlamına geliyor.

Fuel ile artık monolitiğin ötesine geçebiliriz.

Topluluğumuza Katılın:

• Discord

• Twitter

• Website

Zen Boğa Stratejisi (Yığın ETH Stratejisi)

• Ödeme Profili: ETH istifleme balonu ile pürüzsüz kavisli çizgi!

• Gelir: ETH getirileri, Long Squeeth sahiplerinin ödediği günlük primden gelir

• Maksimum Kazanç: Sınırsız

• Maksimum Kayıp: Sınırlı (yatırılan ETH miktarı)

• Likidasyon: Zen Boğa stratejisi pozisyonlarının likide edilmesi mümkün olsa da, %20 gibi bir ETH fiyat hareketi için otomatik yeniden dengelemeler (MWF) ve fiyat bazlı yeniden dengelemeler nedeniyle olasılığı düşüktür.

Zen Boğa için İdeal Piyasa Durumu

Zen Boğa stratejisi, düşük ETH fiyat volatilite dönemlerinde sakin bir şekilde yükselen ETH market koşulu için idealdir (ETH fiyatı sakin olduğunda!).

Spesifik olarak, Zen Bull, Squeeth’in gerçekleştirdiği volatilitenin, Squeeth’in belirttiği volatiliteden daha az olduğu durumlarda (ETH, Squeeth piyasasının beklediğinden daha sakin olduğunda) en iyisini yapar. Zen Boğa ‘uzun delta’ ‘kısa volatilite’ pozisyonudur.

Zen Bull Stratejisi, ETH fiyatına 1: 1 maruz kalan bir pozisyon oluşturmak için kullanıcı ETH bakiyelerini otomatik olarak yönetir (yaklaşık delta 1).

Zen Boğa stratejisi, ETH açısından karlı olmayı amaçlamaktadır (şu ETH’yi istifleyin!). Strateji, getirilerin hızla azaldığı yield farming gibi DeFi yöntemlerine kıyasla sürdürülebilir yöntemlerle (oSQTH satarak) getiri elde eder. Zen Boğa = gerçek yield.

Dikkat edilmesi gereken hususlar:

Mevcut Zen Boğa Kar Eşiği (Fiyat Bantları):

• Zen Bull Stratejisine para yatırmadan önce en önemli husus Zen Bull’un karlılık eşiğidir (fiyat bantları). Fiyat bantları dar olduğunda Zen Boğa Stratejisine para yatırırsanız ve ardından fiyat bantları geniş olduğunda geri çekilirseniz, ucuz olduğunda etkin olarak Squeeth satıyor ve pahalı olduğunda geri alıyorsunuz demektir. Düşük satmak ve yüksek satın almak iyi bir görünüm değil!

• Zen Boğa karlılık eşiği, karlı bir dönemle sonuçlanacak yeniden dengelemeler arasındaki ETH fiyat aralığını gösterir.

• Kar eşiği, Squeeth’in mevcut Zımni volatilitesine (primler) dayanmaktadır. ETH, bir sonraki yeniden dengelemeden (MWF) önce her iki yönde de yaklaşık kar eşiğinden daha fazla hareket ederse, Zen Boğa stratejisi karsız olacaktır.

Varsayımsal Bir Zen Boğa Kar Eşiği (fiyat bantları)

Risk:

Zen Boğa Stratejisinde bakiyeniz için en büyük iki performans riski şunlardır:

• Fiyat bantları dar olduğunda Zen Boğa Stratejisine para yatırırsanız ve ardından fiyat bantları geniş olduğunda para çekerseniz

• ETH, yeniden dengelemeler arasında her iki yönde de yaklaşık olarak kar eşiğinden (fiyat bantları) daha fazla hareket ederse.

Zen Boğa Stratejisi bakiyeleri likide edilebilirken, zamana dayalı veya ETH fiyat değişiklikleri eşiğinde otomatik yeniden dengeleme, bir likidasyonun gerçekleşmesini önlemeye yardımcı olur.

Zen Bull’a bakiye yatırmak için şu adrese gidin https://go.squeeth.com/BestZB

Discord: https://discord.gg/opyn

Twitter: https://twitter.com/opyn_

Squeeth: https://squeeth.opyn.co/

Squeeth’in Dışbükey Getirisi vs “Normal” 2x Kaldıraç Getirisi

• Ödeme Profili: ETH²

• Maliyet: Günlük Prim

• Maksimum Kazanç: Sınırsız

• Maksimum Kayıp: Sınırlı (oSQTH satın almak için yatırılan tutar)

• Likidasyon: Long Squeeth likide EDİLEMEZ

Long Squeeth için İdeal Market Durumu:

Squeeth’i satın almak için ideal piyasa koşulu, bir kullanıcının ETH’nin kısa ve orta vadede yukarı yönlü fiyat hareket etmesine inancının göstermesidir. Squeeth (kare ERTH’nin kısaltması) ETH’yi aşırı yükler ve türevine bir ETH² getirisi verir.

Dikkat edilmesi gereken hususlar:

Zımni Volatilite Squeeth (ZV):

• Uzun süre Squeethlemeden önce dikkat edilmesi gereken en önemli husus, Squeeth’in mevcut zımni volatilitesidir.

• Zımni Volatilite, piyasanın gelecekte ne kadar değişken olabileceğini ölçmek için tasarlanmış ileriye dönük bir metriktir (yüksek ZV sinyalleri, büyük fiyat dalgalanma beklentisi, düşük ZV sinyalleri ise fiyatın sabit kalacağına kanaattir).

• Mevcut Squeeth ZV’yi Referans Vol veya geçmiş Squeeth vol ile karşılaştırmak, satın almanın nispeten pahalı / ucuz bir zaman olup olmadığını belirlemeye yardımcı olabilir.

• İdeal olarak, ZV düşük olduğunda Squeeth satın alır ve daha sonra ZV yüksek olduğunda satarsınız (yani, ucuz olduğunda Squeeth satın alır ve pahalı olduğunda satarsınız)

• ZV yüksek olduğunda Squeeth satın alır ve ardından ZV düşük olduğunda satarsanız, pahalı olduğunda etkin bir şekilde Squeeth satın alır ve ucuz olduğunda satarsınız. Yüksek satın almak ve düşük satmak iyi bir görünüm değil!

• Not: ZV, piyasanın volatilite görüşünü gösterir, ancak gelecekteki ZV seviyelerinin göstergesi değildir.

Prim:

• Squeeth, ETH²’ye eşit olmaktan ziyade onu takip eder çünkü long pozisyonu korumak için shortkara günlük bir prim (fonlama gibi) öder.

• Squeeth’in primi doğrudan Squeeth’in Zımni Volatilitesi ile ilgilidir (yüksek Squeeth ZV = yüksek günlük prim, düşük squeeth ZV = düşük günlük prim)

Risk:

Squeeth’i elinizde tuttuğunuz süre boyunca Squeeth primlerine dikkat edin. ETH’nin yatay işlem gördüğü veya değerinin düştüğü uzun bir süre (> 1 yıl) Long Squeeth pozisyonu tutmak, Squeeth satıcılarına ödenen günlük prim nedeniyle ETH² tarafında bir kayba neden olacaktır.

2 kat kaldıraçlı bir pozisyonla karşılaştırıldığında, Squeeth ETH yükseldiğinde daha fazla kazanacak ve ETH düştüğünde daha az kaybedecektir, ancak saf dışbükeyliğe (ETH² getirisi) maruz kalma nedeniyle prim oranlarının daha yüksek olması beklenmektedir.

Squeeth satın alırsanız, oSQTH Performansını ne etkiler? Bu başlığı okuyun.

Squeeth satın almak için https://go.squeeth.com/BestConditions adresine gidin.

Discord: https://discord.gg/opyn

Twitter: https://twitter.com/opyn_

Squeeth: https://squeeth.opyn.co/

Another good system for DEXs is Orderbook style. Orderbooks works well with high transaction speeds, low transaction fees and enough liquidities. Thanks to these, more and more people are coming to these platforms so by this the volume in these platforms are also naturally increased. However, the biggest disadvantage of this system is the lack of the contribution of small players. People can not add liquidity in these systems since private market makers are providing them. Since private market makers are providing liquidity, mostly they decide to add liquidity on the pairs they find beneficial for themselves. In these kind of platforms, the problem of less trading pairs than the community wants can occur.

A brand new style for the DEXs is Oracle. Oracle style of DEXs have its own advantages and disadvantages. The biggest concern of this system is the uncertainty for the liquidity providers. Liquidity providers have to accept all the orders whether they are beneficial or not. This can be thought as a balance between traders and liquidity providers. When the gains for traders increase, the other side of the balance goes up and results as a loss for the liquidity providers.

Phezzan is bringing a great solution on these existing solutions with major problems, Orderbook Style with Retail Liquidity!

• Thanks to Phezzans orderbook style, traders, liquidity providers and builders can have a great choice in DEX ecosystem. One of the biggest advantage of Phezzan is the user friendly interface which is quite similar to what people are using in CEXs and DEXs.

• Phezzans orderbook style reduces the need of committing major amount for the private market makers which leads them to deploy more on other coin pairs that they find it risky and not that beneficial on other style of DEXs. Phezzan allows them to have better liquidity for more volatile coins!

• Phezzan is democratizing the liquidity for all. Liquidity providers can add liquidity for an orderbook and they can earn more in with other style such as AMM and Oracle!

• Phezzan is opening the gates for being a market maker to everybody! Thanks to the permissionless nature of Phezzan, despite the traditional orderbook style, not only the big players, but also the small players can be a market maker!

• Permissionlessness of Phezzan also allows builders to list their own token pairs and build their own perpetual pairs!

Surprized? Amused? Questions? Please head to the social channel of Phezzan and learn more!

Giriş:

Merhaba Adalialılar,

İlk ödüllü testnetimiz 1000 in üzerinde katılımcı ve sadece 16 saat içinde 11,101 asteroidin mintlenmesi ile oldukça başarılı geçti. Sesimiz daha geniş kitlelere ulaştıkça, Twitter, Discord ve mail listesi aracılığı ile binlerce yeni topluluk üyesi kazandık.

Topluluğumuza katılan herkesin Asama 1 etkinliğine katılamadığını ve çoğunuzun Influence`e dalıp daha çok öğrenip daha çok eğlenip ve ayni zamanda SWAY tokeni kazanmak istediğinizi biliyoruz. O yüzden bu sefer daha çok topluluk üyesinin katılımını sağlamak için ufak bir değişiklik yaptık.

29 Ağustos’tan itibaren Asama 2`ye katılımı tüm topluluk üyelerine açtık.

Asama 2 bizim için, yeni özelliklerin performansı hakkında data toplayabilmek açısından oldukça önemli. Böylece Influence`ı geliştirerek daha güvenilir ve oyuncu tabanlı sıfır risk ortamını eğiterek lansmana hazırlanabiliriz.

Hadi Başlayalım ve Asama 2`yi Keşfedelim

Özellikler

-Layer 1 ve Layer 2 arasında varlık köprüsü

-Asteroidlerin Layer 2 üzerinde mintlenmesi (StarkNet)

-Adaliali alımları (yeni ekip üyelerinin oluşturulması)

-Ekip yönetimi kullanıcı ara yüzü

— Ekip üyelerini yerleştirme

— Kaptan atama

— Ayrıntıları, roller ve meslekleri görüntüleme

Köprü Kullanımı:

Layer 1 ve Layer 2 arasında varlıkları köprü ile transfer etmek, kullanıcılara, varlıklarını daha uygun gördükleri layer üzerinde saklamalarına olanak sağlayan oldukça önemli bir özellik. Oyunu oynayabilmek için astroid ve ekip üyelerinizin layer 2 üzerinde olması gerekli, fakat oyundan uzun sure uzak kalacağınız bir süreçte, varlıklarınıza ekstra bir güvenlik katmanı eklemek istiyorsanız, varlıklarınızı Layer 1`e köprülemek sizin için iyi bir seçenek olacaktır.

Testnet’in bir parçası olarak, köprü kullanımını sorunsuz ve kolay olmasını sağlamaya çalışıyoruz, çünkü bu, resmi olarak sonsuza dek evimiz olarak Starknet’e taşındığımızda, sizlerin deneyiminin büyük bir parçası olacak. Gelecekte edinilen / yaratılan tüm asteroitler ve ekip üyeleri varsayılan olarak yalnızca Layer 2'de olacaktır.

Asterioidlerin mintlenmesi:

Astroid mintleme aslında asteroid satın alma ile aynı şey. Testnette bunu, ücretsiz olan ETH test ağında yapacaksınız yani gerçek ara harcamayacaksınız. Fakat, satın alma işlemi ana oyundakiyle ayni olacaktır.

Adaliali Alımı

Adaliali alımı, oyuncuların kendi yeni ekip üyelerini yarattığı bir oyun içi süreçtir. Adaliali yaratmadan önce, Influence`in hikayesini daha iyi anlayabilmeniz adına size kısa bir video göstereceğiz. Videonun ardından karakterinizi yaratabileceksiniz.

Ekibinizi Oluşturma ve Yönetme:

Adaliali alım sureci sonucunda Adaliali ekip üyenizi yarattıktan sonra, Adalialinizi Ekip Yönetme Konsolu aracılığı ile yönetebilirsiniz. Oyunun özellikleri arasında, kaptan atama, 5`e kadar aktif ekip üyesi seçme ve ekip üyelerinizin özelliklerini görüntüleme imkânları bulunmaktadır

Etkinlik Ne Kadar Sürecek

1. Bolum : 29 Ağustos — 4 Eylül

10,000 mintlenebilir asteroid (hesap başına maksimum 10 adet) Sinirsiz ekip üyesi mintleme (Toplam maksimum 75 milyon SWAY)

2. Bolum: 4 Eylül — 1 Kasım

4 hafta boyunca haftalık 500 asteroid minti (Hesap başına 1 asteroid) Sinirsiz ekip üyesi mintleme (Toplam maksimum 25 milyon SWAY)

Ne Kadar Kazanabilirim ?

Lansmandaki toplam tokenlerin % 1'i (1,5 milyar) Testnet katılımcılarına verilecektir.

SWAY Ödülleri:

-Asteroit Satın Alma: 5.000 SWAY

-Ekip Üyesi Alma: 1,000 SWAY

-L1 — L2 Asteroitleri Köprüleme: 2,500 SWAY

-L2 — L1 Asteroitlerini Köprüleme: 1.000 SWAY

-L1'den L2'ye Ekip Uyesi Köprüleme: 2,500 SWAY

-L2'den L1'e Köprüleme Ekip Uyesi: 1,000 SWAY

NOT: 1 Ekim’den sonra, TestNet Aşama 3 başlatılıncaya kadar kazanımlar durdurulacaktır.

Nasıl teste katılırım?

Discord`umuza katılmanızı öneririz:

https://discord.gg/qX3pzAw9

çünkü tüm soruların ve desteğin yer karşılanacağı yer burasıdır.

TestNet Aşama 2 kılavuzunu takip edin ve Ağustos ayındaki lansmana hazırlanın: https://wiki.influenceth.io/en/gameplay/testnet/phase-two

Namada, Anoma’nın ilk fraktal örneğidir ve Anoma protokolünün v1 sürümünü kullanır. Bu protokol sürümü, Ethereum veya IBC uyumlu zincirler gibi oluşturuldukları platformdan bağımsız olarak her türlü varlık (değiştirilebilir ve değiştirilemez olanlar) için korumalı transferlere olanak tanıyan Anoma bileşenlerinin bir alt kümesini içerir. Namada’yı kullanarak ETH, DAI veya başka herhangi bir değiştirilebilir varlığınızı veya NFT’nizi Ethereum, ATOM veya OSMO’nuzu herhangi bir IBC zincirinden aktarabilir ve bunları birkaç saniyelik işlem gecikmesi ve sıfıra yakın ücretlerle gizli olarak gönderebilirsiniz.

Gizliliği koruyan transferleri son kullanıcılar için daha erişilebilir hale getirmek amacıyla Namada dikey olarak entegre edilmiştir ve 2022'de kullanıcı dostu arayüzlerle piyasaya sürülecektir.

Neden Namada?

Merkezi olmayan protokoller alanındaki ilk işim, katman 1 veya dApp üzerinde çalışan bir kuruluşta değil, blok zincirlerinde kullanıcı verilerini anonimleştirmek için araçlar geliştiren ve bunları kâr amacıyla satan bir şirketteydi. Sadece adreslere, değerlere, zaman damgalarına, etkileşim grafiklerine, kullanım modellerine bakarak veya sadece takma adları OSINT verileriyle eşleştirerek (özellikle insanlar NFT’leri twitter profili olarak kullanıyorsa önemsizdir) ne kadar çok şey söyleyebileceğiniz çılgınca. Ben (kendimi dikkatli bir kullanıcı olarak görüyorum) neredeyse kendimi ifşa ettiğim birkaç durum yaşadım — son derece dikkatli olmanızın gerektiği bu günlerde kullanıcı deneyimi berbat hale geliyor. Kendiniz dikkatli olsanız bile, akranlarınız da yanlışlıkla sizi ifşalayabilir.

Özellikle çok zincirli bir dünyada her türlü değiştirilebilir ve değiştirilemez tokenin daha fazla kullanılmasına yönelik olarak bu alandaki büyüme beni heyecanlandırıyor. Ancak hiçbir protokolde yerel gizlilik desteğinin olmaması, hatta çoğu kullanıcının her etkileşimde ne kadar hassas veri sızdırdıkları ve bu verilerin internete erişimi olan herkes tarafından kendi çıkarları için nasıl kullanılabileceği konusunda çok az veya hiç bilgiye sahip olmaması beni endişelendiriyor.

Eğer ortada bir veri varsa, bu veri birileri tarafından kullanılıyor/ kullanılacak. Bunun henüz gerçekleşmemiş olması, veri piyasası uyumunun henüz gelmediğinin bir göstergesidir.

Merkezi olmayan protokollerin mümkün olduğunca çok sayıda kişi için mevcut merkezi ve sömürücü finansal sistemlere bir alternatif olmasını istiyorum. Bu yüzden yaptığımız işe her baktığımda kendime şunu soruyorum: inşa ettiğimiz şey kullanıcılar için daha mı iyi? Bu, kullanıcılarına asimetrik bir güç ilişkisi dayatan mevcut sistemlerden daha adil bir güç dağılımı sağlıyor mu? Cevabın evet olması için gizlilik çok önemli bir özellik. Blok zincirleri şeffaf olduğu sürece, mevcut sistemlerden çok daha kötü gizlilik garantileri sağlayacaktır çünkü bir full node’a erişimi olan herkes kullanıcıların anonimliklerini ortadan kaldırmak icin temel analizler yapabilir.

Korumalı transferler nasıl gelişti?

2014 yılında yayınlanan Zerocash makalesi, korumalı transferleri mümkün kılmak ve takma isimli işlemlerden daha güçlü gizlilik garantileri sağlamak için zk-SNARK’ların kullanılması fikrine öncülük etmiştir. Bu protokol daha sonra ZCash protokolünün geliştiricileri olan Electric Coin Company tarafından 2016'nın sonlarında hayata geçirildi ve Sprout’tan son NU5'e kadar çok sayıda güncelleme yapıldı — ECC, ZCash’in liderliği ve bu alandaki sürekli katkıları olmasaydı, Namada ile bugün bulunduğumuz noktada olamazdık. Uzun yıllar boyunca, gizliliği koruyan protokoller korumalı transferleri yerel varlıkla birleştirdi, böylece kullanıcılar ZCash üzerinde ZEC kullanmadan korumalı transferler yapamadı.

Son yıllarda, Tornado Cash Nova ve Aztec’in Ethereum’daki ZK Money’si gibi farklı protokol ve platformlarda kriptografi araştırma ve dağıtımında (özellikle sıfır bilgi kanıtı şemaları) bir patlama yaşandı. Bunların en güzel yanı, farklı türden değiştirilebilir varlıklar için gizliliği koruyan transferlere olanak tanımalarıdır: Tornado Cash Nova, ETH ve ZK Money de ETH, DAI, renBTC — gizliliği belirli bir para biriminden ayırmada ileri bir adım.

Bununla birlikte, gizliliği koruyan protokollerin kullanımı henüz normalleşmemiştir ve sahte protokollerin kullanımına kıyasla çok küçüktür.

Namada’yı kendim kullanmaktan ve çoklu zincir kullanıcılarının, hangi zincirde veya platformda oluşturulduklarından bağımsız olarak, değiştirilebilir veya değiştirilemez varlıklar olsun, kullanıcının sahip olduğu her türlü varlıkla korumalı transferler yapmasına olanak tanıyan Namada ile kullanıcıların neler yapacağını görmekten heyecan duyuyorum. Namada’nın temel özelliklerinden biri, tüm varlıkların tek bir anonimlik setini paylaşacak olmasıdır. Bu özellik, özellikle varlık düşük işlem hacmine ve/veya yüksek değere sahip olduğunda gizlilik garantilerini önemli ölçüde zayıflatabilen varlık başına korumalı havuzdan uzaklaşmamızı sağlar; ayrıca, tüm egemen zincirler ve platformlardaki değiştirilebilir ve değiştirilemez varlıklar aynı korumalı havuzu paylaşabileceğinden, çok daha geniş bir anonimlik seti oluşturmamıza olanak tanır.

Namada, protokol düzeyinde birkaç saniyelik gecikme ve sıfıra yakın ücret sağlamanın yanı sıra entegre tarayıcı tabanlı bir arayüzle sorunsuz bir kullanıcı deneyimi sunmayı amaçlayan dikey olarak entegre bir protokoldür. Namada, korumalı havuz kullanıcıları için teşviklerle birlikte geleceği için kriptoekonomi cephesinde de bir deney olacaktır.

Namada’nın Mimarisi Nasıl Görünüyor?

Bu sadece genel bir bakış açısıdır, Anoma specs v1'de güncel ve spesifik bir genel bakış bulacaksınız.

Namada, mutabakat algoritması olarak Tendermint BFT’yi ve sybil direnç mekanizması olarak proof-of-stake’i kullanan ve doğrulayıcıların ağı benzer yapılandırmalarla çalıştırmasını engellemek ve altyapı mimarisinde daha fazla çeşitliliğe sahip bir doğrulayıcı seti ile ağın sağlamlığını artırmak için tasarlanmış F1 ücret dağıtımının otomatik olarak bileşik bir varyantı ve kübik dilimleme yoluyla ödül dağıtım modeli gibi ilerleyen özel bir katman 1 protokolüdür. Namada, yerel olmayan değiştirilebilir ve değiştirilemez tokenleri desteklemek için IBC protokolü ve deterministik kesinliği desteklemeyen platformlarla birlikte çalışabilirliği sağlamak için özel köprülerle entegre edilmiştir (ilk başta Ethereum’a için bir köprü).

Yönetim için Namada’nın iki bileşeni vardır: zincir dışı bir sinyal mekanizması ve zincir içi bir oylama mekanizması. Zincir içi oylama mekanizması, bir geçerlilik yüklemi olarak uygulanma özelliğine sahip basit bir metin tabanlı teklif oylama sistemidir (bu terimi unutmayın, çünkü daha sonraki Anoma protokolü sürümlerinde giderek daha belirgin hale gelecektir). Zincir dışı sinyalizasyon mekanizması, hard fork gerektiren bir teklif olması durumunda doğrulayıcılar arasında bir koordinatör görevi görecek şekilde tasarlanmıştır, böylece operatörler bir sonraki hamle üzerinde anlaşmak için bunu kullanabilir. Başka bir deyişle, yönetim mekanizması, son anlık görüntüye dayalı pay da dahil olmak üzere zincir dışı çalışır.

Namada’nın en son yazılım sürümü, tüm varlıkların tek bir anonimlik setini paylaşmasını sağlayan bir sıfır bilgi devresi olan Çok Varlıklı Korumalı Havuzu (MASP) kullanmaktadır — bu özellik, hem değiştirilebilir hem de değiştirilemez varlıkların aynı korumalı havuzu paylaşmasına izin verdiği için çok önemlidir, böylece gizlilik garantileri söz konusu varlıkla yapılan işlem hacmine tabi değildir. Buna ek olarak, ana ağ Namada, işlemlerde üzerinden gerçekleştirilecek spamları teşvik etmeden protokol enflasyon sübvansiyonları yoluyla korumalı havuz kullanımı için teşvikler sağlamak üzere MASP’nin değiştirilmiş bir versiyonu olan Burn and Mint (B&M) ve Convert Circuit ile birlikte gelecektir.

Namada’ya Nasıl Katılabilirsiniz?

Dikkat etmeniz gereken pek çok şey var:

Yaklaşan Namada güvenilir kurulumuna katılın: Namada’nın yeni parametrelere ihtiyacı olacak. Özellikle Namada’yı korumalı transferler için kullanmaktan heyecan duyuyorsanız, ceremony’ye katılmanızı şiddetle tavsiye ederim. Ne kadar çok katılımcı olursa o kadar iyi olur. Op-sec düşüncelerinizi veya benzersiz rastgelelik kaynağınızı göstermeye ve diğer katılımcılara zehirli atıklardan (kurtarılamaz olması gereken verileri oluşturmak için bireysel olarak kullandığınız gizli bilgiler) kurtulduğunuzu kanıtlamaya hazır olun. Ceremony 2022 yazının ortalarında planlanmaktadır ve teşvik içerebilir.  

Yaklaşan Namada halka açık test ağlarına katılın: Bir doğrulayıcı işleterek ve yönetim yoluyla ağın geleceğini yöneterek ağın güvenliğine katkıda bulunmayı düşünüyorsanız, 2022 yazında teşvik edilebilecek halka açık test ağları için bizi izlemeye devam etmelisiniz.

Namada’yı bir kullanıcı olarak deneyin: Namada’nın korumalı transferlerini, diğer zincirlerden varlıkları köprülemeyi, stake etmeyi, komut satırı istemcisi veya tarayıcı tabanlı arayüz aracılığıyla yönetimde oy kullanmayı deneyin. Mainnet’ten önce, halka açık test ağlarına katılmıyor olsanız bile, kullanıcılardan gelen geri bildirimleri entegre edebilmemiz için arayüzlerin erken sürümleri entegre edilecektir.

Sırada Ne Var?

Gelişmelerden haberdar olmanın en iyi yolu @namadanetwork adresini takip etmek, namada.net adresindeki haber bültenine abone olmak, Trusted Ceremony’ye kaydolmak ve henüz yapmadıysanız Discord’daki Anoma topluluğuna katılmaktır.

Bu böyle olmak zorunda değil.

Ethereum ve Solana da dahil olmak üzere diğer birçok proof-of-stake ekosistemi, bu sorunu çözmek için stake türevlerini barındırıyor ve artık Cosmos’ta da var.

Size son teknoloji ürünü çok zincirli likit stake etme deneyimi olan Stride’ı sunmaktan büyük heyecan duyuyoruz! Stride, kullanıcıların varlıklarını herhangi bir Cosmos zincirinde likit olarak stake etmelerine olanak tanıyacak.

Çıkış Noktası

Birçoğunuz gibi biz de son birkaç yıldır DeFi’yi kullanmayı çok sevdik ve ekosistem genelinde geliştirilen yeniliklerle birlikte yeni mekanizmaların hızı bizi inanılmaz derecede heyecanlandırdı.

Özellikle Cosmos bizi çok etkiledi. Cosmos dışında bile, IBC’nin çoklu zincir iletişiminin geleceği olacağına inanıyoruz. Ayrıca uygulama zincirlerinin geleceğin ta kendisi olduğuna inanıyoruz akıllı sözleşmelerden daha verimli, ölçeklenebilir ve güvenlidirler. Bu inanç bizi 12 ay önce buraya getirdi. O zamandan beri Cosmos’ta büyük, gelişen topluluklar kurduk ve bu alandaki insanların ne kadar inanılmaz olduğunu ilk elden gördük. Ayrıca Cosmos ekosisteminde staking altyapısını çalıştırmaya başladık ve ilgili teknolojiye ve takaslara aşina olduk.

Cosmos’ta stake’in bir sorunu olduğunu fark ettik: kullanıcılar, stake etmenin sunduğu ödüller ile DeFi protokollerinin sunduğu getiri arasında seçim yapmak zorunda kalıyor. Tokenlarınızı stake etmek ağı güvence altına alır ve pasif gelir sağlar, ancak tokenlerinizi kilitlemenizi gerektirir; DeFi’ye katılmak daha yüksek bir getiri elde etmenizi sağlar, ancak sizi daha fazla riske maruz bırakır.

Ancak, IBCv3'ün bu yılın başlarında piyasaya sürülmesinden sonra, bu takasın artık var olması gerekmiyor. Çoklu zincir staking’i desteklemek için gereken tüm teknoloji yayında. Stride’a girin…

Misyon

Misyonumuz, Cosmos’taki kullanıcılara en iyi ve en güvenli likit stake deneyimini sunmaktır. Stride, DeFi’de stake etmenize ve katılmanıza olanak tanır.

Likit stake etmeye niceliksel finans, DeFi, ürün ve mühendislik alanlarında kapsamlı bir geçmişe sahip olarak geldik: sağlam ticaret altyapısı kurduk, en eski DeFi projelerinden bazılarında çalıştık, %100 çalışma süresi doğrulayıcı bir altyapı oluşturduk ve Silikon Vadisi’nin en iyi girişimlerini ölçeklendirdik.

Deneyimlerimiz, inovasyonu teşvik etmeye devam ederken güvenliği sağlamak için aşağıdaki üç alana öncelik vermemizi sağladı:

DeFi güvenliğini en üst düzeyde tutmak. Her zaman. Şu anda önde gelen blok zinciri denetçilerinden ikisi olan Certik ve Oak Security tarafından denetleniyoruz. Ayrıca, pay sahiplerinin fonlarının güvende olduğundan emin olmak için yönetimsel modüllerimiz ve oran sınırlamamız ile yenilikçi önlemler alıyoruz. (Detaylı blog yazısı çok yakında!)

Para piyasalarına, DEX’lere ve diğer mevcut Cosmos DeFi ürünlerine tek tıkla entegrasyonlar sağlayarak stTokens’i Cosmos DeFi’nin temel varlığı haline getirmek — lansmandan sonra tamamen yeni özelliklerimiz olacak. Cosmos DeFi’yi güçlendirmek için likit staking kullanmak istiyoruz.

Kullanıcılara inanılmaz derecede basit, dikey olarak entegre bir Uygulama Kullanıcı Deneyimi sunuyoruz. Yıl sonuna kadar, tümü Stride içinde olmak üzere 15 Cosmos L1 varlığı için likit stake olanağı sunmayı hedefliyoruz. Cosmos, tüm kriptodaki en yenilikçi teknolojilerden bazılarına sahip, aynı zamanda endüstri bir lideri UX’e sahip olduğundan emin olmak istiyoruz.

Cosmos ekosisteminde aktif olan Imperator, Everstake, Staking Facilities, North Island Ventures, Distributed Global, 1Confirmation, Pantera Capital ve diğerleri dahil olmak üzere en iyi doğrulayıcılar ve yatırımcılardan bazılarıyla Stride’ı Cosmos ortamına uygun olarak inşa etmek için ortaklık kurduk.

Yol Haritası

Hızlı hareket ediyoruz ve çok yakında size genel test ağımızı sunacağımız için heyecanlıyız!

Herkese Açık Test Ağı Lansmanı: 6/27 ana ağ lansmanına kadar. Mainnet Lansmanı: Ağustos ayının ilk yarısı

Topluluk

Yakında çok daha heyecan verici duyurularımız olacak, bu yüzden bizi takip ettiğinizden ve topluluğa katıldığınızdan emin olun!

Discord | Twitter | Testnet

Giriş

2022 yılında, on-chain ekosistem, merkeziyetsiz finans protokolleri tarafından oluşturulan muazzam finansal araçlar tarafından devrim yarattı. Kripto sahipleri pasif gelir elde edebilir, kredi alabilir ve merkeziyetsiz evrendeki dijital varlıklarıyla önceki yıllara göre çok daha fazlasını yapabilir. Aşağıda, bu gelişmeyi başlatan iki önemli yeniliği açıklıyoruz:

• Peer-to-Contact Sistemi Tasarımı

Geleneksel olarak, elektronik ticaretin temel yapı taşı emir defteri ve eşleştirme motorunu içerir. Bu model, verimli takası kolaylaştırmak için mükemmeldir ve karmaşık finansal piyasaların oluşturulmasına izin verir. Bununla birlikte, merkeziyetsiz borsalar (DEX’LER) Ethereum blok zincirinde aynı peer-to-peer modeli uyguladığında, emir defteriyle olan her etkileşim gaz ücreti gerektirir ve bu da işlemlerin yürütülmesini pahalı ve sürdürülemez hale getirir. 2020'nin DeFi yazında, Uniswap ve Compound gibi önde gelen protokoller tarafından kullanılan peer-to-peer sistem tasarımının atılımı, fonların akıllı bir sözleşmede yavuzlaştırılmasını teşvik ediyor. Dolayısıyla, geleneksel anlamda diğer tarafta bir satıcı yoktur, bunun yerine kullanıcı, yavuzlaştırılmış akıllı sözleşmedeki likiditeye karşı işlem yürütmektedir. Bu sadece çok daha verimli bir on-chain spot ticaret sistemi oluşturmakla kalmaz, aynı zamanda yield farming, sentetik varlıklar, sigorta vb. Gibi diğer birçok finansal deney için potansiyel oluşturur. Ek olarak, fonlar bir araya getirildiğinde, bir araya gelen katılımcılar, platformun yönetim tokenini kullanarak önemli gördükleri ortak bir neden üzerinde birlikte oy kullanmaları için daha fazla teşvik edilir.

• Merkeziyetsiz Yönetim

Kimse DeFi ekosisteminde geride kalmış ya da sesini duyuramadığını hissetmiyor. Geliştiriciler tüm zor seçimleri yapmak zorunda değildir, çünkü toplulukla etkileşime girebilir ve platformda hangi iyileştirmelerin yapılması gerektiğini, belirli bir özelliğin neden değiştirilmesi gerektiğini ve ekibin fonları veya ortaklıkları nasıl ele alması gerektiğini öğrenebilirler. Bu atmosfer, merkeziyetsizliğin habercisi olan yönetim tokenleri aracılığıyla etkinleştirilen yeni katılımcıları ve fikirleri teşvik eder. Yönetim tokeni sahipleri, platform gelişimine katkıda bulunarak, karar alma sürecinde oy vererek vb. Projeyi ilerletmek için finansal olarak teşvik edilen paydaşlar olarak düşünülebilir. Bu olmadan, projelerin çoğunluğu kendilerini merkeziyetsiz olarak nitelendirme hakkına sahip olamayacaktı. Bununla birlikte, merkeziyetsiz yönetim sistemleri hala erken aşamadadır ve Merkeziyetsiz Özerk Kuruluşlarda (DAO’LAR), merkeziyetsiz kredi sistemlerinde vb. Deneylerle gitmek için uzun bir yol vardır.

Bu yenilikler DeFi alanında sermaye verimliliğini arttırsa bile, özellikle ABD Doları destekli stabil coinlerin piyasaya hakim olduğu bir dönemde, küresel para birimi veya stabil coin türevleri için uygun bir altyapının olmaması gibi bugün hala gözden kaçan ve büyük zorluklar sunan bölümler var. Bu nedenle, Increment, dünya çapındaki insanlar için Defi’nin gücünü açığa çıkaracak merkeziyetsiz bir döviz kuru altyapısı oluşturmayı amaçlamaktadır. Increment protokolünün ilk iterasyonunda, merkeziyetsiz döviz kuru vadesiz takaslarını oluşturuyoruz.

Increment Hakkında Sıkca Sorulan Sorular

Increment mainnet’e ne zaman geçecek?

Testnet, 2022'nin 1. Çeyreğinde aktifleştirilecek ve mainnet’e de bundan birkaç ay sonra geçilecek.

Hangi L2 Ethereum altyapısını inşa etmek istiyorsunuz?

Başlangıç için zkSync 2.0 üzerine inşa ediyoruz, ancak Increment’ın gelecekte yalnızca Zksync’de aktif olmasi pek olası değil. DAO tarafından yönetilen bir protokol yapısına geçtikten sonra, token sahipleri, protokolün ana mühendislerinin görüşleri ile birlikte, diğer L2'lerde veya L1'lerde olsun, çok zincirli bir dağıtım önerebilir ve oy kullanabilirler.

En basit ifadeyle, Increment’te ne yapabilirim?

Kullanıcılar protokolle iki şekilde etkileşime girebilir:

• Kaldıraçlı uzun veya kısa küresel döviz kurları

• Likidite sağlamak ve işlem ücreti kazanmak için para yatırma

Token dağılımı ve ekonomi modeli nedir?

Increment henüz yönetim tokenini çıkarmadı. Tokenomics modeli ve dağıtımı gelecekte piyasaya sürülecek.

Increment için yol haritası nedir?

Genel olarak, Increment protokolü için 2022 yol haritası aşağıdaki gibidir:

Q1:

· zkSync 2.0 ve Aave hibe alıcısı üzerine kurulumu duyurmak

· Pre-Audit ve genel testnet sürümü için kod temeli ve dokümantasyon hazırlama

Q2:

· Herkese açık testnet, hata bulma ve geri bildirim için erken erişim kayıtları ve diğer erken test kullanıcıları için kullanılabilir hale getirilmesi

· Daha fazla stres testi için ek testnet aşamalar başlatma

· Secureum ile Pre-Audit ve Peckshield ile audit tamamlama (bulunan herhangi bir hatanın düzeltilmesi)

Q3:

· Devam eden testnet asamalari ve UX optimizasyonları

· Trail of Bits ile tam Audit (bulunan herhangi bir hatanın düzeltilmesi)

· Increment DAO formasyon önerisini toplulukla tartışma

Q4:

· zkSync 2.0 mainnet’te mainnete geçiş

Uzun vadeli hedefler sabitken, kısa vadeli planların genellikle yeniden düzenlendiğini ve değiştirildiğini unutmayın. Herhangi bir geri bildiriminiz ve yorumunuz varsa, bizimle iletişime geçmekten çekinmeyin Discord