Bir Backend Geliştiricinin Gözünden Blockchain Geliştirme

Herkese iyi günler! Uzun zamandır Backend geliştirme yapıyorum ve son birkaç yıldır giderek daha fazla farklı blockchain projesi yazıyorum (EVM'de Solidity). Blockchain'e dalmak benim için kolay olmadı ve backend beynim birkaç kez bozuldu, bu yüzden blockchain geliştirmeye geçiş yapma konusundaki görüşlerimi paylaşmaya karar verdim.

Blockchain , dünyamızı ileriye taşıyabilecek çok havalı bir teknoloji. Ancak şimdilik, birçok kişi onu satın alma-satış-dolandırıcılık-dolandırıcılık-güçlendirme için kullanıyor. Kriptoyu bir varlık olarak değerlendirmeyi düşünmüyorum ve düşünmüyorum.

Evet, birçok farklı video ve paylaşımda, "İşte şu kripto para şimdi büyüyebilir, şu kripto para da düştü. Beyler yatırım yapalım, alalım..." deniyor. Size bu konuda hiçbir şey söylemeyeceğim.

Sadece bir şey söyleyeceğim - para kazanmak için kriptodan uzak durmalısınız. Eğer bir geliştiriciyseniz, bir geliştirici olarak kazanmaya çalışmak ve yatırımlara girmemek daha iyidir. Ve gerçekten yatırım yapmak istiyorsanız, kriptoya girmeyin.

Blockchain hakkında ve neden ilginç olduğu

Önemli bir notla başlamaya değer. Blockchain, kripto para birimi değildir. Blockchain, kripto para biriminin üzerine inşa edildiği teknolojidir ve kripto para birimini blockchain olarak adlandırmak, tüm geliştirme endüstrisine Javascript demek gibidir. Evet, JavaScript özel bir geliştirme durumu gibi görünüyor, ancak geliştirmeden bahsederken JavaScript'i kastetmiyoruz. Bazı insanlar yalnızca JavaScript'i kastetse de...

Para için blockchain'e geçiyorum

Akla ilk gelen şey paradır. Blockchain geliştiricilerine oldukça iyi ücret ödenir. Ben şahsen bu tür pozisyonlar açtım. Ben şahsen bu tür pozisyonlara yanıt verdim, burada aynı backend geliştiricisinden günde aynı miktarda zaman harcayarak daha fazlasını alabilirsiniz. Blockchain geliştiricileri, blockchain tabanlı girişimlerde ağırlıkları kadar altın değerindedir. Özellikle iyi bir blockchain geliştiricisi!

İyi bir backend geliştiricisi kimdir?

İyi bir arka uç geliştiricisi olmak, bir prod'u düşürmeden veya düzeltmeden imkansızdır. Belki de ben sadece bir kaybedenim ve sadece olumsuz deneyimlerle öğreniyorum, ancak benim teorim bu:

1. Eğer backend geliştiricisi deneyimli ise çözümleri prod'da çalıştırmıştır.
2. Eğer bunu Prod'da çalıştırdıysa, nasıl çalıştığını ve yük altında ürüne ne olduğunu biliyor demektir.
3. Eğer hizmetleri yük altında tutmuşsa, o zaman kesintileri ve hizmet çökmelerini yakalamış demektir.
4. Ve eğer servis kazalarına denk geldiyse, muhtemelen onları da kapmıştır.

Başarısızlıkla deneyiminizi değiştiremezsiniz, ancak başarısızlığın deneyimi, deneyime sahip olduğunuzu fark etmenizi sağlar. Para kaybetmeden iyi bir blockchain geliştiricisi olmak zordur:

• Eğer sözleşmemden henüz para çalınmadıysa, bu gerçek parayla (sözleşmemde en az 1000 dolar) bir şey başlatmadığım anlamına gelir.
• Eğer gerçek parayla veya sadece test ağlarında (sahte parayla) bir şey başlatmadıysam, o zaman blockchain'in toksik dünyasında beni neyin beklediğine dair hiçbir fikrim yok.
• Eğer beni neyin beklediğini bilmiyorsam, ilk lansmanda yanmış olurum ve bu, hatamın bedelini ilk ödeyen olma riskini almaya istekli olan ekibin/şirketin meselesidir.

Teknoloji için blockchain'e girmek

Yukarıdaki resim Wright kardeşlerin dünyadaki ilk uçağını gösteriyor, oldukça kötü uçuyordu. Ama uçuyordu ve o zamanlar ortalama bir insanın uçaklara karşı tutumu aşağı yukarı şöyleydi:

• Masraflı
• Rahatsız edici
• Rahatsız edici, anlaşılmaz

Ve şimdi, havayolu endüstrisi hayatlarımızın harika bir parçası, gezegenin dört bir yanındaki insanları birkaç saat içinde birbirine bağlıyor. Lojistik artık Wright kardeşlerin asla hayal edemeyeceği bir seviyede! Uçaklar sayesinde tüm dünya farklı yaşıyor.

Aynısını şimdi blockchain için de söyleyebilirim - pahalı ve kullanışsız ve nedeni belirsiz. Blockchain geliştirmeye dalana kadar bana yatırımcıları (=hamsterları) dolandırmak için işe yaramaz bir şey gibi görünüyordu. Ancak diğer taraftan bakarsanız, herhangi bir gerçeği kurcalama olasılığı olmadan merkezi olmayan bir şekilde depolamak mümkündür. "Kurcalama olasılığı olmadan" önemli bir ayrıntıdır.

Ama ne yazık ki, "blockchain" kelimesiyle ilgili çağrışımlar oldukça sıkıcı ve monoton:

• Bitcoin
• Yatırım
• Sahtekarlık
• ETH, Ripple, {coin adını girin}
• Patlamak üzere olan balon

Bir deste kağıt parayı sobaya atarsak soba iyi yanar, hatta para bir süre ısı bile verir. Ama bu saçmalık.

Ve blockchain için de durum böyledir. Bunu sadece para ve kripto için kullanmak kötüdür, ancak diğer şey henüz kök salmıyor...

Herhangi bir ürün geliştirmenin temel itici güçlerinden biri paradır. İyi ve güçlü para kazanılacak bir şey varsa, o zaman bu "bir şey" aktif olarak geliştirilecektir. Ve bu yüzden, şimdiye kadar, blockchain tabanlı finansal projeler gerçekten de birisinin para kazanması için para kazanmaya ve başkası için para kaybetmeye dayanmaktadır.

Blockchain Geliştirme Teorisi

Merkeziyetsizlik

Merkezi ve merkezi olmayan hizmet arasındaki fark nedir? Merkezi bir sistemle başlayalım. Ben ve başka biri varız ve bir transferi kolaylaştırmak için aramızda bir banka veya başka bir sağlayıcı gibi bir hizmet kullanmaya karar verdik.

Merkezi bir hizmet olan bir bankamız olduğunu hayal edelim. Bu bankaya şunu emrediyorum: "Lütfen bu kişiye 100 dolar transfer edin." Banka, bende 100 dolar eksik, başkasında ise 100 dolar fazla olduğunu kaydediyor.

Peki merkezi hizmetin sorunu nedir? Bu merkezi hizmetin arkasında bir sahip var, değil mi? Genellikle bazı büyük şirketler, holdingler, fark etmez; bizim durumumuzda, bir kişi olsun. Bu bir kişi şunu söyleyebilir: "Hadi yapalım. Alex 100 dolar göndersin, ancak kimse bu 100 doları almayacak. Onlara daha çok ihtiyacım var."

Merkezi hizmetlerin sahipleri vardır. Sorun, sahibinin parayı elinden alarak olumsuz kararlar alabilmesidir. Ve bu sadece "parayı kendin için almak" ile ilgili olmayabilir. Örneğin, "Bankada 100.500 dolarımız var" yazabilir ve tüm mevduat sahiplerinin o paranın peşine düşmemesini umabilirsiniz... tıpkı SVB ve diğer ölen bankalarda olduğu gibi.

Bitcoin para yönetimini merkeziyetsizleştirmek için icat edildi.

Merkezi olmayan bir hizmet, her düğümün bilgi depoladığı ve ilettiği bir düğüm ağı üzerine kuruludur. Basitçe söylemek gerekirse, düğümler hangi bilginin doğru, hangi bilginin doğru olmadığı ve bunları nasıl depolayacağımız konusunda anlaşmışlardır.

Bir odayla benzetme yapabiliriz - bir kişi diğerlerinin saklamasını istediği bilgiyi bağırır. Sonra, odadaki herkes bağırmanın ardından sakladıkları bilgiyle çalışır.

Örneğin, bir blok zinciri para transferleri hakkında mesajları veya bilgileri depolayabilir ve iletebilir. Ağdaki katılımcılar, kaydetmeden önce bilgileri doğrular.

Oda benzetmesinde, "Sam'e 100 dolar transfer ediyorum" diye bağırıyorum. Herkes benim 100 dolarım eksik, Sam'in ise 100 dolarım fazla olduğunu kaydediyor. Eğer transferden önce aniden 100 dolardan azım olursa, kimse işlemi kaydetmez.

Akıllı sözleşmeler

Blockchain'de, Solidity dilinde akıllı sözleşmeler oluşturabilirsiniz (EVM'deki blockchain durumunda). Akıllı sözleşme, blockchain ağında çalışan bir programdır. Doğrulama mekanizmaları, hata işleme ve diğer işlevleri içerebilir.

Yine, komutları bağırdığımız oda durumunda, akıllı sözleşme, odadaki her katılımcıya program kodunu önceden vermemdir: komutlarıma nasıl tepki verecekleri, neyi kontrol edecekleri ve neyi kaydedecekleri. Ve sonra bağırırım, "Programı bu parametrelerle çalıştır". Sonra, herkes talimatları takip eder. Basit, akıllı sözleşmenin bir örneği, veri ekleme ve alma işlevlerine sahip bilgi depolamadır. Sözleşme kodu bayt koduna derlenir ve yürütme için blok zinciri katılımcılarına geçirilir.

Bu akıllı sözleşmeye gönderilecek belirli istekleri nasıl ele alırız? Arka uçla bir benzetme yaparsak, POST ve GET isteklerini işleyebilen bir hizmettir. POST bilgileri depolar. Buradaki GET, depoladığımız bilgileri geri gönderir. Herhangi bir arka uç genellikle bu şekilde yapılandırılır.

Backend'deki geliştirmem sırasında, API, veritabanı ve veri depolama ve işlemeyle ilgili her şeyin benim tarafımda gerçekleştiği düzenlemeye çok alıştım. Ve ben zaten, sanki bir duvarın arkasındaymış gibi, kullanıcının bu verilerle önceden hazırlanmış bir senaryoya göre çalışması için bir arayüz sağlıyorum.

Örneğin, kullanıcı 1 gelir ve POST yöntemiyle içeriği (örneğin gönderiyi) kaydeder. Sonra, kullanıcı 2 gelir ve bu içeriği GET yöntemini kullanarak alır. Kullanıcılar içeriğin nerede ve nasıl olduğunu bilmezler - arka uç onlar için bir kara kutudur.

Ve burada blockchain'in çok önemli bir kısmına geliyoruz. Bir odada duran düğümler veya kişilerle ilgili örneklerimize geri dönelim. Arka uçla bir benzetme kullanarak, her seferinde şuna sahip olduğumuzu varsayalım: Blockchain'e bir "ADD" yöntemi atıyorum ve sonra herkes yerel olarak yöntemi çağırıyor ve daha sonra blockchain'in kendi kopyasından bilgi alabiliyor.

Yani, ağda düğümlerin bilgi aldığı bir sürü farklı kopyamız var. Blockchain'in sorunu, her yazma işlemi için gerçek para ödememiz gerektiğidir. Bu, gerçek parayla satın alınabilen (veya çıkarılabilen, ancak bugün bundan bahsetmiyoruz) ağ para birimi tarafından ödenir.

Blockchain ve backend’i karşılaştırdığımızda karşımıza çıkan tablo şu şekildedir:

• Geleneksel hizmetlerde ücretsiz olarak yazıyoruz, ücretsiz olarak okuyoruz ve bağımlı olarak
• Blockchain'de ücret karşılığında yazıyoruz ve ücretsiz ve bağımsız bir şekilde okuyoruz

Örneğin, Telegram'ın merkezi bir veritabanı var. Her zaman ücretsiz olarak erişebilir ve mesajlarımızı, fotoğraflarımızı, videolarımızı vb. indirebiliriz. Ancak Telegram'ın sunucuları aniden çökerse, ona erişemeyiz.

EVM sanal makinesinin, blockchain'e bilgi yazma dahil olmak üzere bazı akıllı sözleşme komutlarını yürütmesi için ödeme yapmamız gerekiyor. Bazı hesaplamalar yapıyor, bir şeyler ekliyor, çarpıyor, çarpıyor, çarpıyor ve sonunda blockchain depolamasında, blockchain'e katılan tüm düğümlerde güncellenen yeni bir eser beliriyor.

Herhangi bir ağ katılımcısı, yüzlerce gigabaytlık blok zinciri verisi içeren tam bir düğüm çalıştırabilir ve yerel olarak onunla çalışabilir. Ayrıca, tüm blok zincirini depolamayacak ancak ağdaki tam düğümlere erişip gerekli bilgileri bunlar aracılığıyla alabileceğiniz hafif bir düğüm sürümü de kullanabilirsiniz.

Fikir, blok zincirindeki her girdinin, blok zincirinin durumunda değişikliklerin meydana geldiği bir dizi işlem içeren bir blok olmasıdır. Her ardışık blok, karma algoritmalarına dayalı bir zincirdeki bir öncekine bağlıdır.

Genel olarak, temeldir, ancak akılda tutulması gereken bir şey var - veriler değişirse her hapşırık için ödeme yapmanız gerekir. Bu arada, bir sözleşme dağıtımı da blockchain'de bir kayıttır ve ucuz değildir!

Akıllı sözleşmenin dağıtımı

Arka uç dünyasında, aşağı yukarı şu özellik geliştirme yaşam döngüsüne alışkınım:

• Kodu yazdım
• Gitlab'da başlattım
• GitLab CI testleri çalıştırır, her şeyi kontrol eder
• Her şey yolundaysa, CI uygulamanın yeni bir sürümünü sunucuya dağıtmaya başlar

Yani, bu şekilde çalışmaya alışkınız ve bu ücretsiz gerçekleşiyor. Koşullu olarak ücretsiz olsa da, çünkü sunucular için ödeme yapıyoruz. Peki ya blockchain?

Blockchain durumunda, "uygulamamızın" (akıllı sözleşme) yeni kodunu blockchain'e yazmamız gerekir. Yukarıda yazdığım gibi, her kayıt için ödeme yapmamız gerekir. Akıllı sözleşmemize bir işlem yapmadan önce, akıllı sözleşmenin yerleştirilmesiyle bir işlem yapmamız gerekir.

Daha sonra istemci/servis sunucusu sözleşmedeki bilgileri almak veya kaydetmek için herhangi bir düğümle iletişime geçecektir.

Çok sayıda düğüme bildirim yapılması gerekiyor - "arkadaşlar, işte işlemlerimde algoritmaları yapılması gereken sözleşmenin bayt kodu". Blockchain'i öğrenen tüm düğümlerde aynı kodun göründüğünden ve kimin çağırdığına ve nasıl çağırıldığına bakılmaksızın aynı şekilde yürütüleceğinden emin olmak zorunludur. Mekanikler aynı ve değişmez olacaktır. Dahası, akıllı sözleşmenin herhangi bir düğümde farklı şekilde çalışması için bir şekilde değiştirilmesinin bir yolu yoktur.

Aşağıda uzun zaman önce ETH ağına bir sözleşme yatırdığım bir işlemin örneği yer almaktadır.

Gerçekte hiç kullanılmamış bir test sözleşmesiydi. Dağıtımı için 200 dolar ETH ödedim. Yani, bu sözleşmeyle henüz hiçbir şey yapmamıştık - tek bir istek bile yoktu, ancak 200 dolar harcanmıştı. Yanlış sözleşmenin bu hatalı dağıtımını hatırladığımda hala üzülüyorum...

Veri depolama

Veri depolama hakkında konuşalım. Hepimiz arka uçta verilerle rahatça çalışmamızı sağlayan PostgreSQL , MySQL , MongoDB , Redis ve diğer hizmetlere sahip olmaya alışkınız. Blockchain söz konusu olduğunda buna yakın bir şey bile yok.

Blockchain'de depolama, diğer dillerdeki bir sınıftaki değişkenler gibi uygulanır. Yani, sadece anahtar değerler veya diziler. Uygun bağlantıları olan ilişkisel tablolar yoktur, vb. Sadece - bir değişkene yazın ve mutlu olun.

Şu anda, blockchain'de depolamayı organize etmenin başka bir yolunu bilmiyorum. Peki, belki durum çoktan değişmiştir; belki bunu okurken, böyle bir yol vardır - yorumlara yazın.

Örneğin, sadece bir dizide saklamak istemiyorsak? Ve bilgileri anahtara göre saklamak istiyorsak - bunun için bir eşleme var.

Dolar işaretinin çizilmesinin bir nedeni var - her set için ağ komisyonu alınacak.

Ağrılar ve sızılar

Bu blokta beni şaşırtan veya kızdıran şeyleri tartışacağım. Bu belgede olanlardan çok daha fazlası var, ancak pratiğimde beni ilk etkileyen şeyleri paylaşacağım.

Çoğu "acı"nın mantıksal bir nedenden ötürü anlaşılabilir olduğunu belirtmek önemlidir. Ancak bu, arka uç beynimdeki acıları ortadan kaldırmaz.

Örneğin, herhangi bir şeyin tüm öğelerinden kolayca geçebileceğimiz gerçeğine alışkınım. Bir dizi, bir nesne veya bir harita olması önemli değil. Solidity'de, bu amaçla, tüm anahtarların bir dizisini ayrı ayrı depolamamız ve sonra, gerekirse, hepsini gözden geçirip her anahtar için haritadan öğeleri almamız gerekecek. Ayrıca, bu anahtar dizisine ve başlatılmasına ek yazma için de gaz harcıyoruz.

Ayrıca kullanışlı anahtar sıralama araçlarının hepsini de alamıyoruz.

Günlük kaydı

Günlük kaydıyla ilgili durum da tatsızdır. Geliştirme ortamında hata ayıklayıcı aracılığıyla hata ayıklamaya alışkınım, ancak burada normal günlük kaydını bile unutmalısınız.

Typescript'te, sadece console.log(a) yazmaya ve çıktıyı hemen konsolda almaya alışkınım. Solidity'de, yalnızca yerel hardhat geliştirme ortamında çalışırken çalışan console.log var. Ve harika olan şey, ihtiyacım olanı böldükten sonra, sözleşme dağıtılmadan önce tüm bu günlükleri silmem gerekiyor çünkü aksi takdirde, sözleşme daha ağır basıyor ve dağıtılması daha maliyetli oluyor ve prod'da hiç çalışmıyor.

Sonuç olarak, projeyi savaşta çalıştırdığımızda, neyin yanlış olduğunu görmek istiyoruz, neyin yanlış gittiğini göremiyoruz. Ama neyin doğru gittiğini görebiliyoruz. Akıllı sözleşmeler içinde bir olay sistemi var. İşte bir örnek: Diyelim ki bu endeksin altına bu değerle yeni bir öğenin eklendiği bir olay istiyoruz.

Bu olayı set metodunun içinde çağırırız ve yalnızca başarılı bir şekilde yürütüldüğünde günlükleri görebiliriz. Bir şeyler ters gittiyse, sözleşmelere birden fazla çağrı yaptıysanız veya bir işlem çökmesi yaşadıysanız, günlükler de kaydedilmez çünkü blockchain'deki bilgiler geri alınır.

Birkaç akıllı sözleşmeden oluşan bir zincir kullandığınızı varsayalım. İlk sözleşmede bazı olaylar çağrılır, sonra ikinci sözleşme çağrılır, bu da diğer olayları çağırır ve sonra çağrılan her şey ikinci sözleşmenin içine düşer. Her şey bir kez ve herkes için tamamen silinecektir.

Blockchain içerisinde neler olup bittiğini kayıt altına almak istediğimizde çok dikkatli olmalıyız ve alıştığımız normal kayıt altına alma işleminin burada bizim için mümkün olmadığını aklımızda tutmalıyız.

Bir diğer kötü şey ise, bir yazma fonksiyonunda işlemlerimizden bilgi alamamamızdır. Blockchain'e bir şey yazan bir işlem yaparsak (yani ücretli bir işlem), return akıllı sözleşmeyle bütünleşen hizmetimize hiçbir şey vermeyecektir. Bu dönüş yalnızca akıllı sözleşmenin kendisinde veya view (ücretsiz) fonksiyonlarında çalışır.

Örneğin, blok zincirimize yeni bir değer eklediğimizde, kaydettikten sonra depolama boyutunu bulmak isteyebiliriz (yukarıdaki ekran görüntüsü). Yani, yalnızca olaylar aracılığıyla tam olarak neyin eklendiğini öğrenebiliriz. Ve bunu yapmak için, o işlem içinde tetiklenen olayları çekmemiz gerekir.

Dizelerle çalışma

Burada benim için bir sürpriz vardı - normalde dizelerle çalışmak imkansızdır. Blockchain dizeler için oluşturulmamıştır. Örneklere geçelim.

Aşağıdaki kod herhangi bir sorun olmadan çalışacaktır.

Ve bu kod artık çalışmayacak:

Uzun zamandır dizelerle normal şekilde çalışmaya, dizelerdeki karakterleri değiştirmeye, dizeleri kesmeye, bunları birleştirmeye alışkınım - bunların hiçbiri kutudan çıktığı gibi mevcut değil. Ayrıca dize uzunluğunu görüntüleme olanağı da yok. Yani, bu kod derlenmeyecek:

Bir dizenin uzunluğuna gerçekten ihtiyacınız varsa, onu baytlara dönüştürebilir ve ardından bayt sayısını sayabilirsiniz. Ancak sorun, bazı özel karakterlerin 1v1 baytlara dönüştürülmemesidir. Bazıları ise basitçe dönüştürülmez ve işlem çökebilir.

Dizelerle ilgilenen ve normal dizeler üzerinde testler yapan bir akıllı sözleşme yazmakla sonuçlanabilirsiniz. Sonra, işlenmeyecek bir dize gelir ve her şey çöker veya dize uzunluğu özel karakterler nedeniyle yanlış sayılır.

Dizelerle ilgili sonuç basittir: dizelerle çalışmayın ve sözleşmenin içindeki dizelere güvenmeyin. Dizelerden tasarruf etmek önemliyse, baytlardan tasarruf edin ve baytlara güvenin ve dizeleri servisin kendisinde baytlara dönüştürün.

Harici arama sorunu

Blockchain'in ana özelliğinin bir uzantısı olan bir sonraki karmaşıklık, izolasyondur. Blockchain'de bulunan tüm veriler ya blockchain'in içinde doğar ya da dışarıdan ona iletilir. Ancak blockchain'in kendisi asla dış dünyaya vuramaz - yalnızca diğer akıllı sözleşmelere vurabilir.

Sorun, tüm akıllı sözleşme komutlarının ağdaki her katılımcıda yürütülmesidir. Ve her düğümde aynı bilginin alınacağından emin olamayacağınız için harici bir kaynağa güvenemezsiniz. Her düğümün farklı verilerle farklı bir blok zinciri sürümüne sahip olması ve blok zincirinin çökmesi söz konusu olacaktır.

Ve "dışarıdaki mevcut sıcaklığı elde etme" gibi önemsiz bir görev imkansız bir şeye dönüşür. Her zaman hava durumuna ihtiyacımız olmasa da, bazı veriler (döviz kurları veya bazı harici sistemlerin mevcut durumu gibi) önemlidir. Çözüm şu yaklaşımda yatmaktadır:

1. Bir Operatör Sözleşmemiz var, servisimiz "şu sunucuya şu parametrelerle bir istek yap" gibi bir görev gönderiyor.
2. Sözleşme Olayı yayar
3. Ayrı bir arka uç bu olaya abone olur, olaydan bilgi çıkarır, "isteğin nereye ve hangi parametrelerle gönderileceğini" söyler ve "bunu bu sözleşmeye buraya koy" cevabını verir.
4. Sunucu isteği doğru parametrelerle gönderir, yanıtı alır
5. Sunucu gerekli sözleşmeye cevabı gönderir.
6. Bundan sonra ne olacaksa bu verilerle aynı olacak.

Çok uzun bir zincir olduğu ortaya çıkıyor. Hikayenin üzücü yanı, paranın ilk "böyle bir istekte bulunun" şeklindeki isteğimde ve isteği gerçekleştiren sunucu tarafından zaten yapılmış olan ikinci istekte alınmasıdır.

Örneğin, her adım için 50k gaz harcıyoruz. İşlemi başlatıyoruz, 50k GAZ LİMİTİ koyuyoruz ve iyi olacağımızı düşünüyoruz. Ancak, örneğin, yeni havayı kaydetme mekaniği değişiyor - şimdi, sıcaklık 10 derecenin üzerinde olduğunda, katılımcılardan birine para aktarmamız gerekiyor. Mantık genişliyor ve şimdi, örneğin, işlem başına 80k gaz harcıyor.

Sonunda, ikinci işlemde bile, işlem için gaz eksikliğinden dolayı tüm zincir çöker. Dış çağrılar etrafında böyle bir "sebze bahçesi" bu tür projeleri daha karmaşık hale getirir. Büyük olasılıkla, dış dünyayla sert bir bağlantınız varsa, projeniz için blockchain'i seçmemelisiniz.

Önceden belirlenemeyen normal bir rastgelelik de yoktur. Bu rastgelelik farklı sağlayıcılar tarafından "olduğu gibi" sağlanır - akıllı sözleşmeye düzenli olarak sadece rastgele bir değer yazılır. Ancak gerçek finansal projeler için böyle bir şeye güvenmek tehlikelidir.

block.timestamp değişkeninin değerinin blok madencisi tarafından ayarlanması özel bir ilgiyi hak ediyor. Elbette, madencinin bloğu kendisinin çıkardığını önceden bileceğini ve zamanı değiştirebileceğini hayal etmek zor. Yine de varsayımsal bir olasılık var. Bu tehlike 15 saniye bağlamında önemlidir ve dakikalara ve büyük zaman aralıklarına güvenirsek, böyle bir sorun yoktur.

Güvenlik sorunları

Güvenlik hakkında çok fazla konuşmayı planlamıyorum. Ancak önemli bir hususu vurgulayacağım: Blockchain'deki her şey herkes tarafından görülebilir. Başkalarının erişemediği tek şey özel anahtarınızdır. Akıllı sözleşme kodu, denetimlerden geçebilmesi ve akıllı sözleşme kullanıcılarının güvenebilmesi için açıkta bırakılır.

Denetim prosedürü, bir şirketin akıllı sözleşme koduna bakması ve bu belirli sözleşmenin bu adres altında yayınlandığını doğrulaması için işe alınması anlamına gelir. Sözleşmenin güvenliği konusu kontrol edilir ve geliştiricilerin beyan ettiği şeyi yapar. Daha sonra, denetim şirketi web sitesinde "bu sözleşme tarafımızca doğrulandı - güvenilir olabilir" gibi bilgiler yayınlar.

Değişmez değişkenler

Ancak sözleşme kodu sağlanmasa bile, kolayca derlenebilir. Örneğin, aşağıdaki kodda değişmez bir değişken vardır - aşağıdaki kodda her yerde bir sabitle değiştirilir.

Bu sözleşmeyi dağıttıktan ve decompiler aracılığıyla açtıktan sonra aşağıdakileri görüyoruz:

Yani değişkenin bu değerini hemen elde ediyoruz.

Özel değişkenler

Arka planda sakin olmaya alışkınım ve bellek erişimi olmadan okunacak özel değişkenlerin değeri sorunlu olacak. Burada da aynı - sadece herkesin "bellek"e erişimi var.

Değişkeni amount private olarak adlandırdık. Akıllı sözleşmeyi dağıtın ve ardından değerini basit bir kod parçasıyla çekin:

Bu şekilde her şeyi çekip çıkarabilirsiniz. Bu yüzden akıllı sözleşmede hassas bir şey saklamayı düşünmeyin!

Akıllı Sözleşme Dağıtımı

Değişikliklerinizi geri almak temelde imkansızdır. Akıllı bir sözleşme bir kez tahsisi kaldırılır ve hiçbir şey değiştirilemez. Zamanın sonuna kadar ve daha da fazlasına kadar blok zincirinde kalacaktır.

Yükseltilebilir Akıllı Sözleşmeler

Bu yüzden her şeyi bir kerede doğru ve iyi yazmanız gerekiyor. Bunu yapamam, bu yüzden hemen ilginç bir geçici çözüm buldum - Yükseltilebilir Sözleşmeler . Mekanikleri şu şekilde çalışır.

1. Sözleşmenin ilk versiyonu (Sözleşme V1) yayınlandı

2. Bir Proxy Sözleşmesi yayınlanır ve şu görevi vardır: 1v1'den gelen tüm istekleri Sözleşme V1'e iletmek veya kendi depolama alanını kullanarak yalnızca hedef sözleşmedeki mantığı kullanmak.

3. Ayrıca kullanıcı, ana sözleşmeyle olduğu gibi proxy sözleşmesiyle de iletişim kurar.

   Sözleşmenin güncellenmesi gerekiyorsa, yönetici Contract V2'yi dağıtır ve admin-contract aracılığıyla proxy-contract'a uygulamanın artık Contract V2 adresinde olduğunu söyler.

4. Daha sonra kullanıcı proxy ile de iletişime geçer ve Contract V2'deki mekanikler çalıştırılmış olur.

5. Daha sonra kullanıcı proxy ile de iletişime geçer ve Contract V2'nin mekaniği çalıştırılmış olur.

Bu mekanizmanın bir dizi sınırlaması ve hilesi vardır. Örneğin, önceki sürümdeki değişkenler sözleşmenin yeni sürümünde değiştirilemez. Bir değişkene artık ihtiyaç duyulmuyorsa, yine de bırakılmalı ve yeni sözleşmeye boşaltılmalıdır.

Elbette, bu çözüm ve diğer pek çok çözümün hazır çözümleri var. Bu geliştirmelerin ana tedarikçisi OpenZeppelin'dir . Bu nedenle, neyse ki, tekerleği yeniden icat etmeye gerek yok.