Ethereum nasıl çalışır?

 

Kaynak: r/ethereum

Giriş

Muhtemelen, ne olduğunu bilseniz de bilmeseniz de Ethereum blok zincirini duymuşsunuzdur. Bazı büyük dergilerin kapağı da dahil olmak üzere son zamanlarda haberlerde çokça yer aldı, ancak Ethereum’un tam olarak ne olduğuna dair bir temeliniz yoksa bu makaleleri okumak anlamsız gelebilir. Peki nedir? Özünde, dijital işlemlerin kalıcı bir kaydını tutan halka açık bir veri tabanı. Daha da önemlisi, bu veri tabanı, onu korumak ve güvenceye almak için herhangi bir merkezi otorite gerektirmez. Bunun yerine, bireylerin üçüncü bir tarafa VEYA birbirlerine güvenmeye ihtiyaç duymadan eşler arası işlemler yapabileceği bir çerçeve olan “güvenilmez” bir işlem sistemi olarak çalışır.

Hala kafan karışık mı? İşte bu yazı burada devreye giriyor. Amacım, Ethereum’un karmaşık matematik veya korkutucu görünen formüller olmadan teknik düzeyde nasıl çalıştığını açıklamak. Bir programcı olmasanız bile umarım en azından teknolojiyi daha iyi kavrarsınız. Bazı parçalar çok teknikse ve okunması zorsa sorun değil! Her küçük ayrıntıyı anlamaya gerçekten gerek yok. Sadece olayları geniş bir çerçevede anlamaya odaklanmanızı öneririm.

Bu yazıda ele alınan konuların çoğu, sarı kağıtta(yellow paper) tartışılan kavramların bir dökümüdür. Ethereum’u anlamayı kolaylaştırmak için kendi açıklamalarımı ve diyagramlarımı ekledim. Teknik zorluğu üstlenecek kadar cesur olanlar, Ethereum sarı kağıdını(yellow paper) da okuyabilir.

Yellow paper nedir?

White Paper’dan daha detaylı teknik bilgiler içeren dokümantasyona yellow paper denir.

Ethereum yellow paper: https://ethereum.github.io/yellowpaper/paper.pdf

Hadi başlayalım!

Blockchain’in tanımı

Bir blok zinciri, “paylaşımlı durumlu, kriptografik olarak güvenli bir işlemsel tekil makinedir”. [1] Bu çok karışık değil mi? Hadi onu parçalayalım.

• “Cryptographically secure”, dijital para biriminin yaratılmasının, kırılması son derece zor olan karmaşık matematiksel algoritmalar tarafından güvence altına alınması anlamına gelir. Bir çeşit güvenlik duvarı düşünün. Sistemi aldatmayı neredeyse imkansız hale getirirler (ör. sahte işlemler oluşturma, işlemleri silme vb.)
• “Transactional singleton machine”, sistemde oluşturulan tüm işlemlerden sorumlu olan tek bir kurallı makine örneğinin olduğu anlamına gelir. Başka bir deyişle, herkesin inandığı tek bir küresel gerçek vardır.
• “With shared-state”, bu makinede depolanan durumun paylaşıldığı ve herkese açık olduğu anlamına gelir.

Ethereum, bu blockchain paradigmasını uygular.

Ethereum blockchain paradigması açıklandı

Ethereum blok zinciri esasen işlem tabanlı bir durum makinesidir. Bilgisayar biliminde, bir durum makinesi, bir dizi girdiyi okuyacak ve bu girdilere dayanarak yeni bir duruma geçecek bir şeyi ifade eder.

Ethereum’un durum makinesiyle, bir “genesis durumu” ile başlıyoruz. Bu, ağ üzerinde herhangi bir işlem yapılmadan önce boş bir sayfaya benzer. İşlemler yürütüldüğünde, bu oluşum durumu bazı nihai durumlara geçiş yapar. Zamanın herhangi bir noktasında, bu son durum, Ethereum’un mevcut durumunu temsil eder.

Ethereum’un durumunda milyonlarca işlem var. Bu işlemler “bloklar” olarak gruplandırılmıştır. Bir blok bir dizi işlem içerir ve her blok bir önceki blokla birlikte zincirlenir.

Bir durumdan diğerine geçişi sağlamak için bir işlemin geçerli olması gerekir. Bir işlemin geçerli sayılabilmesi için madencilik olarak bilinen bir doğrulama sürecinden geçmesi gerekir. Madencilik, bir grup düğümün (yani bilgisayarların) geçerli bir işlem bloğu oluşturmak için işlem kaynaklarını harcamasıdır.

Ağda kendisini madenci olarak ilan eden herhangi bir düğüm, bir blok oluşturmaya ve doğrulamaya çalışabilir. Dünyanın dört bir yanından birçok madenci aynı anda bloklar oluşturmaya ve doğrulamaya çalışıyor. Her madenci, blok zincirine bir blok gönderirken matematiksel bir “kanıt” sağlar ve bu kanıt bir garanti görevi görür: Kanıt varsa, blok geçerli olmalıdır.

Bir bloğun ana blok zincirine eklenmesi için madencinin bunu diğer tüm rakip madencilerden daha hızlı kanıtlaması gerekir. Bir madencinin matematiksel bir kanıt sağlamasını sağlayarak her bloğu doğrulama süreci, “proof of work” olarak bilinir.

Yeni bir bloğu onaylayan bir madenci, bu işi yaptığı için belirli bir değerle ödüllendirilir. Bu değer nedir? Ethereum blok zinciri, “Ether” adı verilen içsel bir dijital belirteç kullanır. Bir madenci bir bloğu her kanıtladığında, yeni Ether jetonları üretilir ve verilir.

Merak ediyor olabilirsiniz: Herkesin tek bir blok zincirine bağlı kalmasının garantisi nedir? Kendi blok zincirlerini oluşturmaya karar verecek bir madenci alt kümesinin olmadığından nasıl emin olabiliriz?

Daha önce, bir blok zincirini, paylaşımlı duruma sahip işlemsel tekil bir makine olarak tanımlamıştık. Bu tanımı kullanarak, doğru mevcut durumun herkesin kabul etmesi gereken tek bir küresel hakikat olduğunu anlayabiliriz. Birden çok duruma (veya zincire) sahip olmak tüm sistemi mahveder çünkü hangi durumun doğru olduğu konusunda anlaşmak imkansız olurdu. Zincirler birbirinden ayrılırsa, bir zincirde 10, diğerinde 20 ve diğerinde 40 jeton sahibi olabilirsiniz. Bu senaryoda, hangi zincirin en “geçerli” olduğunu belirlemenin bir yolu olmayacaktır.

Birden çok yol oluşturulduğunda, bir “çatal(fork)” oluşur. Genellikle çatallardan kaçınmak isteriz, çünkü bunlar sistemi bozar ve insanları hangi zincire inanacaklarını seçmeye zorlar.

Hangi yolun en geçerli olduğunu belirlemek ve çoklu zincirleri önlemek için Ethereum, “Hayalet protokol(GHOST protocol)” adı verilen bir mekanizma kullanır.

“GHOST” = “Açgözlü En Ağır Gözlemlenen Alt Ağaç”

Basit bir ifadeyle, GHOST protokolü, üzerinde en fazla hesaplamanın yapıldığı yolu seçmemiz gerektiğini söylüyor. Bu yolu belirlemenin bir yolu, mevcut yoldaki toplam blok sayısını temsil eden en son bloğun (yaprak blok(leaf block)) blok numarasını kullanmaktır (genesis bloğunu saymaz). Blok numarası ne kadar yüksek olursa yol o kadar uzun olur ve yaprağa(leaf block) ulaşmak için harcanması gereken madencilik çabası o kadar büyük olur. Bu akıl yürütmeyi kullanmak mevcut durumun standart versiyonu üzerinde anlaşmamıza izin verir.

Artık bir blok zincirinin ne olduğuna dair 10.000 fit’lik genel bir bakış elde ettiğinize göre, Ethereum sisteminin oluşturduğu ana bileşenleri daha derinlemesine inceleyelim:

• hesaplar
• durum
• gaz ve ücretler(gas and fees)
• işlemler(transactions)
• bloklar
• işlem yürütme
• madencilik(mining)
• işin kanıtı(proof of work)

Başlamadan önce bir not: Ne zaman X’in “karması” desem, Ethereum’un kullandığı KECCAK-256 karmasından bahsediyorum.

Hesaplar(Accounts)

Ethereum’un küresel “paylaşılan durumu”, bir mesaj iletme çerçevesi aracılığıyla birbirleriyle etkileşime girebilen birçok küçük nesneden (“hesaplar”) oluşur. Her hesabın kendisiyle ilişkili bir durumu ve 20 baytlık bir adresi vardır. Ethereum’daki her bir adres, herhangi bir hesabı tanımlamak için kullanılan 160 bitlik bir tanımlayıcıdır.

İki hesap türü vardır:

• Özel anahtarlar tarafından kontrol edilen ve kendileriyle ilişkili hiçbir kodu olmayan harici olarak sahip olunan hesaplar.
• Sözleşme kodları tarafından kontrol edilen ve kendileriyle ilişkili kodu olan sözleşme hesapları.

Harici olarak sahip olunan hesaplar ve sözleşmeli hesaplar

Harici olarak sahip olunan hesaplar ile sözleşmeli hesaplar arasındaki temel farkı anlamak önemlidir. Harici olarak sahip olunan bir hesap, kendi özel anahtarını kullanarak bir işlem oluşturup imzalayarak harici olarak sahip olunan diğer hesaplara VEYA diğer sözleşme hesaplarına mesaj gönderebilir. Harici olarak sahip olunan iki hesap arasındaki bir mesaj, yalnızca bir değer aktarımıdır. Ancak, harici olarak sahip olunan bir hesaptan bir sözleşme hesabına gönderilen bir mesaj, sözleşme hesabının kodunu etkinleştirerek çeşitli eylemleri gerçekleştirmesine izin verir. (örneğin, jetonları transfer etme, dahili depolamaya yazma, yeni jetonlar basma, bazı hesaplamalar yapma, yeni sözleşmeler oluşturma vb.)

Harici olarak sahip olunan hesapların aksine, sözleşme hesapları kendi başlarına yeni işlemler başlatamaz. Bunun yerine, sözleşme hesapları işlemleri yalnızca aldıkları diğer işlemlere yanıt olarak tetikleyebilir (harici olarak sahip olunan bir hesaptan veya başka bir sözleşme hesabından). “İşlemler ve Mesajlar” bölümünde sözleşmeden sözleşmeye aramalar hakkında daha fazla bilgi edineceğiz.

Bu nedenle, Ethereum blok zincirinde meydana gelen herhangi bir eylem, her zaman harici olarak kontrol edilen hesaplardan başlatılan işlemlerle harekete geçirilir.

Hesap durumu(Account state)

Hesap durumu, hesap türünden bağımsız olarak mevcut olan dört bileşenden oluşur:

• nonce: Hesap harici olarak sahip olunan bir hesapsa, bu numara hesabın adresinden gönderilen işlem sayısını temsil eder. Hesap bir sözleşme hesabıysa ,nonce, hesap tarafından oluşturulan sözleşmelerin sayısıdır.
• balance: Bu adresin sahip olduğu Wei sayısı. Ether başına 1e+18 Wei vardır.
• storageRoot: Bir Merkle Patricia ağacının kök düğümünün karma değeri. (Merkle ağaçlarını daha sonra açıklayacağız) Bu ağaç, bu hesabın depolama içeriğinin hash değerini kodlar ve varsayılan olarak boştur.
• codeHash: Bu hesabın EVM (Ethereum Sanal Makinesi — bundan sonra bahsedeceğiz) kodunun karması. Sözleşme hesapları için bu, hash yapılan ve codeHash olarak depolanan koddur. Harici olarak sahip olunan hesaplar için codeHash alanı, boş dizenin karma değeridir.

Dünya durumu(World state)

Tamam, Ethereum’un küresel durumunun hesap adresleri ve hesap durumları arasındaki bir eşleştirmeden oluştuğunu biliyoruz. Bu eşleme, Merkle Patricia ağacı olarak bilinen bir veri yapısında saklanır .

Bir Merkle ağacı (veya “Merkle trie”), aşağıdakilere sahip bir dizi düğümden oluşan bir ikili ağaç türüdür:

• ağacın altında temel verileri içeren çok sayıda yaprak düğümü
• her düğümün iki alt düğümünün karması olduğu bir dizi ara düğüm
• ağacın tepesini temsil eden, iki alt düğümünün karmasından da oluşan tek bir kök düğüm

Ağacın altındaki veriler, depolamak istediğimiz verileri parçalara bölerek, ardından parçaları kovalara bölerek ve ardından her bir kovanın karma değerini alarak ve kalan toplam karma sayısı olana kadar aynı işlemi tekrarlayarak oluşturulur. Sadece bir tane kök hash(root hash) vardır.

Bu ağacın içinde depolanan her değer için bir anahtara sahip olması gerekir. Ağacın kök düğümünden başlayarak, anahtar, yaprak düğümlerinde depolanan değere ulaşmak için hangi alt düğümü izleyeceğinizi söylemelidir. Ethereum’un durumunda, durum ağacı için anahtar/değer eşlemesi, her hesap için bakiye, nonce, codeHash ve storageRoot dahil olmak üzere adresler ve ilişkili hesaplar arasındadır.

Bu aynı trie yapısı, işlemleri ve makbuzları saklamak için de kullanılır. Daha spesifik olarak, her blok, aşağıdakiler dahil olmak üzere üç farklı Merkle trie yapısının kök düğümünün karmasını depolayan bir “başlığa” sahiptir:

1. State trie
2. Transactions trie
3. Receipts trie

The ability to store all this information efficiently in Merkle tries is incredibly useful in Ethereum for what we call “light clients” or “light nodes.” Remember that a blockchain is maintained by a bunch of nodes. Broadly speaking, there are two types of nodes: full nodes and light nodes. (ÇEVİREMEDİM)

Tam bir arşiv düğümü, genesis bloğundan mevcut ana bloğa kadar tüm zinciri indirerek blok zincirini senkronize eder ve içerdiği tüm işlemleri yürütür. Tipik olarak madenciler, madencilik süreci için bunu yapmaları gerektiğinden, tam arşiv düğümünü depolar. Her işlemi gerçekleştirmeden tam bir düğüm indirmek de mümkündür. Ne olursa olsun, herhangi bir tam düğüm tüm zinciri içerir.

Ancak bir düğümün her işlemi yürütmesi veya geçmiş verileri kolayca sorgulaması gerekmedikçe, tüm zinciri depolamaya gerçekten gerek yoktur. Hafif düğüm kavramı burada devreye girer. Tüm zinciri indirip depolamak ve tüm işlemleri yürütmek yerine, hafif düğümler, herhangi bir işlem veya işlem yürütmeden, genesis bloğundan mevcut başlığa kadar yalnızca başlıklar zincirini indirir. herhangi bir ilişkili durumu alma. Hafif düğümler, üç denemenin karmalarını içeren blok başlıklarına erişime sahip olduklarından, işlemler, olaylar, bakiyeler vb. hakkında kolayca doğrulanabilir cevaplar üretebilir ve alabilirler.

Bunun işe yaramasının nedeni, Merkle ağacındaki karmaların yukarı doğru yayılmasıdır — kötü niyetli bir kullanıcı sahte bir işlemi bir Merkle ağacının altına değiştirmeye çalışırsa, bu değişiklik yukarıdaki düğümün karma değerinde bir değişikliğe neden olur ve bu da bunun üzerindeki düğümün hash’i ve sonunda ağacın kökünü değiştirene kadar böyle devam eder.

Bir veri parçasını doğrulamak isteyen herhangi bir düğüm, bunu yapmak için “Merkle kanıtı” adı verilen bir şey kullanabilir. Bir Merkle kanıtı(Merkle proof) şunlardan oluşur:

1. Doğrulanacak bir veri yığını ve karma değeri
2. Ağacın kök karması
3. “Dal” (tüm ortak, yığından köke giden yol boyunca ilerler)

Kanıtı okuyan herkes, o dal için hash değerinin ağaç boyunca tutarlı olduğunu ve dolayısıyla verilen yığının aslında ağaçta o konumda olduğunu doğrulayabilir.

Özetle, bir Merkle Patricia ağacı kullanmanın yararı, bu yapının kök düğümünün, ağaçta depolanan verilere kriptografik olarak bağımlı olması ve dolayısıyla kök düğümün karma değerinin bu veriler için güvenli bir kimlik olarak kullanılabilmesidir. Blok başlığı durum, işlemler ve makbuz ağaçlarının kök karmasını içerdiğinden, herhangi bir düğüm, potansiyel olarak sınırsız olabilen tüm durumu depolamaya gerek kalmadan Ethereum durumunun küçük bir bölümünü doğrulayabilir.

Gas Ücretleri ve ödeme

Ethereum’daki çok önemli bir kavram, ücret kavramıdır. Ethereum ağındaki bir işlemin sonucu olarak meydana gelen her hesaplama bir ücrete tabidir — bedava öğle yemeği yok! Bu ücret “gaz” adı verilen bir değerde ödenir.

Gaz , belirli bir hesaplama için gereken ücretleri ölçmek için kullanılan birimdir. Gaz fiyatı , her bir gaz birimi için harcamak istediğiniz Ether miktarıdır ve “gwei” ile ölçülür. “Wei”, ¹⁰¹⁸ Wei’nin 1 Eteri temsil ettiği Eter’in en küçük birimidir. Bir gwei 1.000.000.000 Wei’dir.

Gönderici, her işlemde bir gaz limiti ve gaz fiyatı belirler . Gaz fiyatı ve gaz limitinin çarpımı , gönderenin bir işlemi gerçekleştirmek için ödemeye hazır olduğu maksimum Wei miktarını temsil eder.

Örneğin, göndericinin gaz sınırını 50.000 ve gaz fiyatını 20 gwei olarak belirlediğini varsayalım. Bu, gönderenin bu işlemi gerçekleştirmek için en fazla 50.000 x 20 gwei = 1.000.000.000.000.000 Wei = 0.001 Eter harcamaya istekli olduğu anlamına gelir.

Gaz limitinin, gönderenin para harcamak istediği maksimum gazı temsil ettiğini unutmayın. Hesap bakiyelerinde bu maksimumu karşılayacak kadar Ether varsa, gidebilirler. Gönderici, işlemin sonunda kullanılmamış gaz için iade edilir ve orijinal kur üzerinden değiştirilir.

Göndericinin işlemi gerçekleştirmek için gerekli gazı sağlamaması durumunda işlem “gazsız” olur ve geçersiz sayılır. Bu durumda, işlem işleme durdurulur ve meydana gelen herhangi bir durum değişikliği tersine çevrilir, böylece işlemden önceki Ethereum durumuna geri döneriz. Ek olarak, hangi işlemin denendiğini ve nerede başarısız olduğunu gösteren, başarısız işlemin bir kaydı kaydedilir. Ve makine, gaz bitmeden önce hesaplamaları yapmak için zaten çaba harcadığından, mantıksal olarak, göndericiye gazın hiçbiri iade edilmez.

Bu gaz parası tam olarak nereye gidiyor? Gönderici tarafından gaza harcanan tüm para, genellikle madencinin adresi olan “lehtar” adresine gönderilir. Madenciler hesaplamaları yürütmek ve işlemleri doğrulamak için çaba harcadıklarından, madenciler gaz ücretini ödül olarak alırlar.

Tipik olarak, göndericinin ödemeye razı olduğu gaz fiyatı ne kadar yüksekse, madencinin işlemden elde ettiği değer de o kadar büyük olur. Bu nedenle, madencilerin onu seçme olasılığı daha yüksek olacaktır. Bu şekilde madenciler, hangi işlemleri doğrulamak veya yoksaymak istediklerini seçmekte özgürdür. Göndericilere hangi gaz fiyatını belirleyecekleri konusunda rehberlik etmek için madenciler, işlem yapacakları minimum gaz fiyatını ilan etme seçeneğine sahiptir.

Depolama ücreti de var

Gaz yalnızca hesaplama adımlarını ödemek için değil, aynı zamanda depolama kullanımı için ödeme yapmak için de kullanılır. Toplam depolama ücreti, kullanılan 32 baytın en küçük katıyla orantılıdır.

Depolama ücretlerinin bazı nüanslı yönleri vardır. Örneğin, artan depolama, tüm düğümlerdeki Ethereum durum veritabanının boyutunu artırdığından, depolanan veri miktarını küçük tutmak için bir teşvik vardır. Bu nedenle, bir işlemin depoya girişi temizleyen bir adımı varsa, o işlemin gerçekleştirilme ücretinden feragat edilir ve depolama alanı açılması için para iadesi yapılır.

Ücretlerin amacı nedir?

Ethereum’un çalışma şeklinin önemli bir yönü, ağ tarafından yürütülen her bir işlemin her tam düğüm tarafından aynı anda etkilenmesidir. Ancak, Ethereum Sanal Makinesindeki hesaplama adımları çok pahalıdır. Bu nedenle, Ethereum akıllı sözleşmeleri, ağa yük getirebilecek dosya depolama, e-posta veya makine öğrenimi gibi daha karmaşık kullanımlar yerine, basit iş mantığını çalıştırmak veya imzaları ve diğer kriptografik nesneleri doğrulamak gibi basit görevler için en iyi şekilde kullanılır. Ücretleri dayatmak, kullanıcıların ağa aşırı yük binmesini engeller.

Ethereum tam bir Turing dilidir. (Kısacası, Turing makinesi herhangi bir bilgisayar algoritmasını simüle edebilen bir makinedir (Turing makinelerine aşina olmayanlar için bunu ve bunu kontrol edin ). Bu, döngülere izin verir ve Ethereum’u durma sorununa duyarlı hale getirir . bir programın sonsuz çalışıp çalışmayacağını belirleyemez.Ücretler olmasaydı, kötü niyetli bir aktör, herhangi bir yansıma olmaksızın bir işlem içinde sonsuz bir döngü yürüterek ağı kolayca bozmaya çalışabilir.Böylece ücretler, ağı kasıtlı saldırılardan korur.

“Neden depolama için de para ödememiz gerekiyor?” diye düşünüyor olabilirsiniz. Hesaplama gibi, Ethereum ağında depolama, tüm ağın yükünü üstlenmesi gereken bir maliyettir.

İşlem ve mesajlar

Ethereum’un işlem tabanlı bir durum makinesi olduğunu daha önce belirtmiştik. Başka bir deyişle, farklı hesaplar arasında gerçekleşen işlemler, Ethereum’un küresel durumunu bir durumdan diğerine taşıyan şeydir.

En temel anlamda, işlem, harici olarak sahip olunan bir hesap tarafından oluşturulan, seri hale getirilen ve ardından blok zincirine gönderilen kriptografik olarak imzalanmış bir talimat parçasıdır.

İki tür işlem vardır: mesaj çağrıları ve sözleşme oluşturma (yani yeni Ethereum sözleşmeleri oluşturan işlemler).

Tüm işlemler, türlerinden bağımsız olarak aşağıdaki bileşenleri içerir:

• nonce : Gönderici tarafından gönderilen işlem sayısı.
• gasPrice : Göndericinin işlemi gerçekleştirmek için gereken gaz birimi başına ödemeye hazır olduğu Wei sayısı.
• gasLimit : Göndericinin bu işlemi gerçekleştirmek için ödemeye razı olduğu maksimum gaz miktarı. Bu miktar, herhangi bir hesaplama yapılmadan önce önceden belirlenir ve ödenir.
• to: alıcının adresi. Sözleşme oluşturan bir işlemde, sözleşme hesabı adresi henüz mevcut değildir ve bu nedenle boş bir değer kullanılır.
• value(değer) : göndericiden alıcıya aktarılacak Wei miktarı. Sözleşme oluşturan bir işlemde bu değer, yeni oluşturulan sözleşme hesabında başlangıç ​​bakiyesi olarak hizmet eder.
• v, r, s : işlemin göndericisini tanımlayan imzayı oluşturmak için kullanılır.
• init (yalnızca sözleşme oluşturan işlemler için mevcuttur): Yeni sözleşme hesabını başlatmak için kullanılan bir EVM kod parçası. init yalnızca bir kez çalıştırılır ve ardından atılır. init ilk çalıştırıldığında , sözleşme hesabıyla kalıcı olarak ilişkilendirilen kod parçası olan hesap kodunun gövdesini döndürür.
• data (yalnızca mesaj çağrıları için mevcut olan isteğe bağlı alan): mesaj çağrısının giriş verileri (yani parametreler). Örneğin, bir akıllı sözleşme bir etki alanı kayıt hizmeti olarak hizmet veriyorsa, bu sözleşmeye yapılan bir çağrı, etki alanı ve IP adresi gibi girdi alanları bekleyebilir.

“ Hesaplar ” bölümünde, işlemlerin — hem mesaj çağrıları hem de sözleşme oluşturan işlemlerin — her zaman harici olarak sahip olunan hesaplar tarafından başlatıldığını ve blok zincirine gönderildiğini öğrendik. Bunu düşünmenin başka bir yolu da, dış dünya ile Ethereum’un iç durumu arasında köprü kuran şeyin işlemler olduğudur.

Ancak bu, sözleşmelerin diğer sözleşmelerle konuşamayacağı anlamına gelmez. Ethereum’un durumunun küresel kapsamında var olan sözleşmeler, aynı kapsamdaki diğer sözleşmelerle konuşabilir. Bunu “mesajlar” veya “dahili işlemler” yoluyla diğer sözleşmelere yapıyorlar. Mesajları veya dahili işlemleri, harici olarak sahip olunan hesaplar tarafından oluşturulmamaları arasındaki büyük farkla, işlemlere benzer olarak düşünebiliriz. Bunun yerine, sözleşmeler tarafından üretilirler. İşlemlerin aksine serileştirilmeyen ve yalnızca Ethereum yürütme ortamında bulunan sanal nesnelerdir.

Bir sözleşme, başka bir sözleşmeye dahili bir işlem gönderdiğinde, alıcı sözleşme hesabında bulunan ilişkili kod yürütülür.

Unutulmaması gereken önemli bir nokta, dahili işlemlerin veya mesajların gasLimit içermemesidir. Bunun nedeni, gaz limitinin orijinal işlemin harici yaratıcısı (yani, harici olarak sahip olunan bir hesap) tarafından belirlenmesidir. Harici olarak sahip olunan hesabın belirlediği gaz limiti, sözleşmeden sözleşmeye mesajlar gibi bu işlemin sonucunda ortaya çıkan alt yürütmeler dahil olmak üzere işlemi gerçekleştirmek için yeterince yüksek olmalıdır. İşlemler ve mesajlar zincirinde, belirli bir mesaj yürütmesinin gazı biterse, o mesajın yürütülmesi, yürütme tarafından tetiklenen sonraki mesajlarla birlikte geri döner. Ancak, üst yürütmenin geri alınması gerekmez.

Bloklar

Tüm işlemler “bloklar” halinde gruplandırılmıştır. Bir blok zinciri, birbirine zincirlenmiş bir dizi bu tür blok içerir.

Ethereum’da bir blok şunlardan oluşur:

• blok başlığı
• o bloğa dahil edilen işlem seti hakkında bilgi
• geçerli bloğun ommers için bir dizi başka blok başlığı .

Ommers açıklaması

“Ommer” nedir? Ommer, ebeveyni mevcut bloğun ebeveyninin ebeveynine eşit olan bir bloktur. Ommer’ların ne için kullanıldığına ve bir bloğun neden ommer’lar için blok başlıklarını içerdiğine hızlı bir dalış yapalım.

Ethereum’un oluşturulma şekli nedeniyle, blok süreleri Bitcoin gibi diğer blok zincirlerinden (~10 dakika) çok daha düşüktür (~15 saniye). Bu, işlemlerin daha hızlı işlenmesini sağlar. Bununla birlikte, daha kısa blok sürelerinin dezavantajlarından biri, madenciler tarafından daha rekabetçi blok çözümlerinin bulunmasıdır. Bu rakip bloklar aynı zamanda “artık bloklar” olarak da adlandırılır (yani, mayınlı bloklar ana zincire girmez).

Ommer’ların amacı, madencileri bu yetim blokları dahil ettikleri için ödüllendirmeye yardımcı olmaktır. Madencilerin içerdiği omerler “geçerli” olmalıdır, yani mevcut bloğun altıncı neslinde veya daha küçüğünde. Altı çocuktan sonra, eski ve öksüz bloklara artık başvuru yapılamaz (çünkü daha eski işlemleri dahil etmek işleri biraz karmaşıklaştırır).

Ommer blokları, tam bloktan daha küçük bir ödül alır. Bununla birlikte, madencilerin bu yetim blokları dahil etmeleri ve bir ödül toplamaları için hala bazı teşvikler var.

Başlık bloğu

Bir an için bloklara geri dönelim. Her bloğun bir “başlığı” olduğundan daha önce bahsetmiştik ama bu tam olarak nedir?

Bir blok başlığı, bloğun aşağıdakilerden oluşan bir kısmıdır:

• parentHash : ana bloğun başlığının bir karması (blok setini “zincir” yapan şey budur)
• ommersHash : mevcut bloğun ommers listesinin bir karması
• beneficiary : bu bloğun madenciliği için ücretleri alan hesap adresi
• stateRoot : durum denemesinin kök düğümünün karması (durum denemesinin başlıkta saklandığını ve hafif istemcilerin durum hakkında herhangi bir şeyi doğrulamasını kolaylaştırdığını nasıl öğrendiğimizi hatırlayın)
• TransactionRoot : Bu blokta listelenen tüm işlemleri içeren denemenin kök düğümünün karması
• ReceivesRoot : bu blokta listelenen tüm işlemlerin makbuzlarını içeren denemenin kök düğümünün karması
• logsBloom : günlük bilgilerinden oluşan bir Bloom filtresi (veri yapısı)
• difficulty(zorluk) : bu bloğun zorluk seviyesi
• number(sayı) : mevcut bloğun sayısı (genesis bloğunun blok numarası sıfırdır; sonraki her blok için blok numarası 1 artar)
• gasLimit : blok başına mevcut gaz limiti
• gasUsed : bu bloktaki işlemler tarafından kullanılan toplam gazın toplamı
• timestamp(zaman damgası) : bu bloğun başlangıcındaki unix zaman damgası
• extraData : bu blokla ilgili ekstra veriler
• mixHash : nonce ile birleştirildiğinde bu bloğun yeterli hesaplama yaptığını kanıtlayan bir karma
• nonce : mixHash ile birleştirildiğinde, bu bloğun yeterli hesaplama yaptığını kanıtlayan bir karma

Her blok başlığının aşağıdakiler için nasıl üç trie yapısı içerdiğine dikkat edin:

• durum ( stateRoot )
• işlemler ( transactionsRoot )
• makbuzlar ( receiptsRoot )

Bu trie yapıları, daha önce tartıştığımız Merkle Patricia denemelerinden başka bir şey değildir.

Ek olarak, yukarıdaki açıklamadan açıklığa kavuşturmaya değer birkaç terim vardır. Hadi bir bakalım.

Logs(Kayıt defteri)

Ethereum, çeşitli işlemleri ve mesajları izlemeyi mümkün kılmak için günlüklere izin verir. Bir sözleşme, günlüğe kaydetmek istediği “olayları” tanımlayarak açıkça bir günlük oluşturabilir.

Bir günlük girişi şunları içerir:

• kaydedicinin hesap adresi,
• bu işlem tarafından gerçekleştirilen çeşitli olayları temsil eden bir dizi konu ve
• bu olaylarla ilişkili herhangi bir veri.

Günlükler , sonsuz günlük verilerini verimli bir şekilde depolayan bir çiçeklenme filtresinde(bloom filter) saklanır.

İşlem makbuzu(Transaction receipt)

Başlıkta depolanan günlükler, işlem makbuzunda yer alan günlük bilgilerinden gelir. Bir mağazadan bir şey satın aldığınızda bir makbuz aldığınız gibi, Ethereum da her işlem için bir makbuz oluşturur. Beklediğiniz gibi, her makbuz, işlemle ilgili belirli bilgileri içerir. Bu makbuz aşağıdaki gibi öğeleri içerir:

• blok numarası(the block number)
• blok karma(block hash)
• işlem karması(transaction hash)
• cari işlem tarafından kullanılan gaz
• cari işlem gerçekleştirildikten sonra mevcut blokta kullanılan kümülatif gaz
• mevcut işlem yürütülürken oluşturulan günlükler
• ..ve benzeri

Engelleme zorluğu

Bir bloğun “zorluğu”, blokları doğrulamak için gereken sürede tutarlılığı sağlamak için kullanılır. Genesis bloğunun zorluğu 131.072'dir ve bundan sonraki her bloğun zorluğunu hesaplamak için özel bir formül kullanılır. Belirli bir blok önceki bloktan daha hızlı doğrulanırsa, Ethereum protokolü o bloğun zorluğunu arttırır.

Bloğun zorluğu, iş kanıtı algoritması kullanılarak bir blok madenciliği yapılırken hesaplanması gereken bir karma olan nonce’yi etkiler.

Bloğun zorluğu ve nonce arasındaki ilişki matematiksel olarak şu şekilde formüle edilir:

Hd zorluğu nerede?

Zorluk eşiğini karşılayan bir nonce bulmanın tek yolu, tüm olasılıkları sıralamak için iş kanıtı algoritmasını kullanmaktır. Bir çözüm bulmak için beklenen süre, zorlukla orantılıdır — zorluk ne kadar yüksek olursa, nonce’yi bulmak o kadar zorlaşır ve dolayısıyla bloğu doğrulamak o kadar zor olur, bu da yeni bir çözümü doğrulamak için gereken süreyi artırır. engellemek. Böylece, bir bloğun zorluğunu ayarlayarak protokol, bir bloğu doğrulamanın ne kadar süreceğini ayarlayabilir.

Öte yandan, doğrulama süresi yavaşlıyorsa, protokol zorluğu azaltır. Bu şekilde, doğrulama süresi, ortalama olarak her 15 saniyede bir blok olmak üzere sabit bir hızı korumak için kendi kendine ayarlanır.

İşlem Yürütme

Ethereum protokolünün en karmaşık bölümlerinden birine geldik: bir işlemin yürütülmesi. İşlenmek üzere Ethereum ağına bir işlem gönderdiğinizi varsayalım. İşleminizi dahil etmek için Ethereum durumunu değiştirmek için ne olur?

İlk olarak, tüm işlemlerin yürütülebilmesi için bir başlangıç ​​gereksinimleri kümesini karşılaması gerekir. Bunlar şunları içerir:

• İşlem, uygun şekilde biçimlendirilmiş bir RLP olmalıdır . “RLP”, “Yinelemeli Uzunluk Öneki” anlamına gelir ve iç içe geçmiş ikili veri dizilerini kodlamak için kullanılan bir veri biçimidir. RLP, Ethereum’un nesneleri seri hale getirmek için kullandığı formattır.
• Geçerli işlem imzası.
• Geçerli işlem nonce. Bir hesabın nonce’sinin, o hesaptan gönderilen işlemlerin sayısı olduğunu hatırlayın. Geçerli olması için, bir işlemin nonce’si gönderen hesabının nonce’sine eşit olmalıdır.
• İşlemin gaz limiti , işlem tarafından kullanılan içsel gaza eşit veya ondan büyük olmalıdır . İç gaz şunları içerir:

1. işlemin gerçekleştirilmesi için önceden tanımlanmış 21.000 gaz maliyeti
2. işlemle birlikte gönderilen veriler için bir gaz ücreti (sıfıra eşit her veri veya kod baytı için 4 gaz ve sıfır olmayan her veri veya kod baytı için 68 gaz)
3. İşlem sözleşme yaratan bir işlem ise, ek 32.000 gaz

• Gönderenin hesap bakiyesinde , gönderenin ödemesi gereken “peşin” gaz maliyetlerini karşılamaya yetecek kadar Ether bulunmalıdır. Peşin alınan gaz maliyetinin hesaplanması basittir: İlk olarak, maksimum gaz maliyetini belirlemek için işlemin gaz limiti işlemin gaz fiyatı ile çarpılır . Daha sonra bu maksimum maliyet, göndericiden alıcıya aktarılan toplam değere eklenir.

İşlem, geçerlilik için yukarıdaki tüm gereksinimleri karşılıyorsa, bir sonraki adıma geçiyoruz.

İlk olarak, gönderenin bakiyesinden peşin yürütme maliyetini düşeriz ve cari işlemi hesaba katmak için gönderenin hesabının nonce’sini 1 artırırız. Bu noktada işlem için toplam gaz limiti eksi kullanılan içsel gaz olarak kalan gazı hesaplayabiliriz .

• Kendi kendini imha etme seti : işlem tamamlandıktan sonra atılacak bir dizi hesap (varsa).
• Günlük serisi : sanal makinenin kod yürütmesinin arşivlenmiş ve dizine eklenebilir kontrol noktaları.
• Geri ödeme bakiyesi : İşlem sonrasında gönderici hesabına iade edilecek tutar. Ethereum’da depolamanın maliyetli olduğundan ve göndericiye depolamayı temizlemesi için geri ödeme yapıldığından bahsettiğimizi hatırlıyor musunuz? Ethereum bunu bir geri ödeme sayacı kullanarak takip eder. Geri ödeme sayacı sıfırdan başlar ve sözleşme depodaki bir şeyi her sildiğinde artar.

Ardından, işlemin gerektirdiği çeşitli hesaplamalar işlenir.

İşlemin gerektirdiği tüm adımlar tamamlandıktan sonra, geçersiz bir durum olmadığı varsayılarak, göndericiye iade edilecek kullanılmamış gaz miktarı belirlenerek durum kesinleşir. Kullanılmayan gaza ek olarak, göndericiye yukarıda açıkladığımız “geri ödeme bakiyesinden” bir miktar ödenek de iade edilir.

Göndericiye para iadesi yapıldığında:

• gaz için eter madenciye verilir
• işlem tarafından kullanılan gaz, blok gaz sayacına eklenir (bloktaki tüm işlemler tarafından kullanılan toplam gazın kaydını tutar ve bir bloğu doğrularken kullanışlıdır)
• kendini imha setindeki (varsa) tüm hesaplar silinir

Son olarak, yeni durum ve işlem tarafından oluşturulan bir dizi günlük kaldı.

Artık işlem yürütmenin temellerini ele aldığımıza göre, sözleşme oluşturan işlemler ile mesaj çağrıları arasındaki bazı farklara bakalım.

Sözleşme oluşturma

Ethereum’da iki tür hesap olduğunu hatırlayın: sözleşmeli hesaplar ve harici olarak sahip olunan hesaplar. Bir işlemin “sözleşme yaratan” olduğunu söylediğimizde, işlemin amacının yeni bir sözleşme hesabı oluşturmak olduğunu kastediyoruz.

Yeni bir sözleşme hesabı oluşturmak için öncelikle özel bir formül kullanarak yeni hesabın adresini bildiriyoruz. Ardından yeni hesabı şu şekilde başlatıyoruz:

• nonce’yi sıfıra ayarlama
• Gönderici , işlemle birlikte değer olarak bir miktar Ether gönderdiyse , hesap bakiyesini bu değere ayarlamak
• Bu yeni hesabın bakiyesine eklenen değerin göndericinin bakiyesinden düşülmesi
• Depolamayı boş olarak ayarlama
• Sözleşmenin codeHash değerini boş bir dizenin karması olarak ayarlama

Hesabı başlattığımızda , işlemle birlikte gönderilen başlangıç ​​kodunu kullanarak hesabı gerçekten oluşturabiliriz (başlangıç ​​kodunu tazelemek için “İşlem ve mesajlar” bölümüne bakın). Bu başlatma kodunun yürütülmesi sırasında olanlar çeşitlidir. Sözleşmenin kurucusuna bağlı olarak, hesabın deposunu güncelleyebilir, başka sözleşme hesapları oluşturabilir, başka mesaj aramaları yapabilir, vb.

Bir sözleşmeyi başlatma kodu yürütülürken gaz kullanır. İşlemin kalan gazdan daha fazla gaz kullanmasına izin verilmez. Olursa, yürütme gazın bitmesi (OOG) istisnasına çarpacak ve çıkacaktır. Gaz çıkışı istisnası nedeniyle işlemden çıkılırsa, durum işlemden hemen önceki noktaya döndürülür. Göndericiye, tükenmeden önce harcanan gazın iadesi yapılmaz .

Boo hoo.

Ancak gönderen işlemle birlikte herhangi bir Ether değeri gönderdiyse, sözleşme oluşturma başarısız olsa bile Ether değeri iade edilecektir. Vay!

Başlatma kodu başarıyla yürütülürse, nihai bir sözleşme oluşturma maliyeti ödenir. Bu bir depolama maliyetidir ve oluşturulan sözleşme kodunun boyutuyla orantılıdır (yine bedava öğle yemeği yok!) Bu nihai maliyeti ödemek için yeterli gaz yoksa, işlem tekrar gaz dışı istisna ilan eder ve iptal eder.

Her şey yolunda giderse ve istisnasız bu noktaya kadar gidersek, kalan kullanılmamış gaz işlemin asıl göndericisine iade edilir ve artık değiştirilen durumun devam etmesine izin verilir!

Yaşasın!

Mesaj aramaları

Bir mesaj çağrısının yürütülmesi, birkaç farkla, bir sözleşme oluşturma işlemine benzer.

Yeni hesap oluşturulmadığından bir mesaj çağrısı yürütmesi herhangi bir başlatma kodu içermez. Ancak, bu veriler işlemi gönderen tarafından sağlanmışsa, giriş verilerini içerebilir. Bir kez yürütüldükten sonra, mesaj çağrıları ayrıca, sonraki bir yürütmenin bu verilere ihtiyacı varsa kullanılan, çıktı verilerini içeren ekstra bir bileşene sahiptir.

Sözleşme oluşturmada olduğu gibi, gazın bitmesi veya işlemin geçersiz olması (örneğin yığın taşması, geçersiz atlama hedefi veya geçersiz talimat) nedeniyle bir mesaj çağrısı yürütme çıkarsa, kullanılan gazın hiçbiri orijinal arayan kişiye iade edilmez. . Bunun yerine, kalan kullanılmamış gazın tamamı tüketilir ve durum, bakiye transferinden hemen önceki noktaya sıfırlanır.

Ethereum’un en son güncellemesine kadar, sisteme verdiğiniz tüm gazı tüketmeden bir işlemin yürütülmesini durdurmanın veya geri almanın bir yolu yoktu. Örneğin, arayanın bazı işlemleri gerçekleştirme yetkisi olmadığında hata veren bir sözleşme yazdığınızı varsayalım. Ethereum’un önceki sürümlerinde, kalan gaz hala tüketilecek ve gönderene hiçbir gaz iade edilmeyecekti. Ancak Bizans güncellemesi, bir sözleşmenin yürütmeyi durdurmasına ve durum değişikliklerini geri almasına, kalan gazı tüketmeden ve başarısız işlem için bir neden döndürme yeteneğine sahip yeni bir “geri alma” kodu içerir. Geri dönüş nedeniyle bir işlemden çıkılırsa, kullanılmayan gaz göndericiye iade edilir.

Yürütme modeli

Şimdiye kadar, bir işlemin baştan sona yürütülmesi için gerçekleşmesi gereken bir dizi adım hakkında bilgi edindik. Şimdi, işlemin VM içinde gerçekte nasıl yürütüldüğüne bakacağız.

Protokolün, işlemleri gerçekten işleyen kısmı, Ethereum’un Ethereum Sanal Makinesi (EVM) olarak bilinen kendi sanal makinesidir.

EVM, daha önce tanımlandığı gibi, Turing’in eksiksiz bir sanal makinesidir. EVM’nin tipik bir Turing komple makinesinin sahip olmadığı tek sınırlama, EVM’nin doğal olarak gazla bağlı olmasıdır. Bu nedenle, yapılabilecek toplam hesaplama miktarı, sağlanan gaz miktarı ile doğal olarak sınırlıdır.

Ayrıca, EVM yığın tabanlı bir mimariye sahiptir. Yığın makinesi, geçici değerleri tutmak için son giren ilk çıkar yığınını kullanan bir bilgisayardır.

EVM’deki her yığın öğesinin boyutu 256 bittir ve yığının maksimum boyutu 1024'tür.

EVM, öğelerin sözcük adresli bayt dizileri olarak depolandığı belleğe sahiptir. Bellek uçucudur, yani kalıcı değildir.

EVM ayrıca depolama alanına sahiptir. Belleğin aksine, depolama kalıcıdır ve sistem durumunun bir parçası olarak korunur. EVM, program kodunu yalnızca özel talimatlarla erişilebilen sanal bir ROM’da ayrı olarak depolar . Bu şekilde, EVM , program kodunun bellekte veya depolamada depolandığı tipik von Neumann mimarisinden farklıdır .

EVM’nin ayrıca kendi dili vardır: “EVM bayt kodu.” Sizin veya benim gibi bir programcı Ethereum üzerinde çalışan akıllı sözleşmeler yazdığında, genellikle Solidity gibi daha yüksek seviyeli bir dilde kod yazarız. Daha sonra bunu EVM’nin anlayabileceği EVM bayt koduna kadar derleyebiliriz.

Tamam, şimdi yürütmeye geçelim.

Belirli bir hesaplamayı yürütmeden önce, işlemci aşağıdaki bilgilerin mevcut ve geçerli olduğundan emin olur:

• Sistem durumu
• Hesaplama için kalan gaz
• Yürütülen kodun sahibi olan hesabın adresi
• Bu yürütmeyi başlatan işlemin göndericisinin adresi
• Kodun yürütülmesine neden olan hesabın adresi (orijinal gönderenden farklı olabilir)
• Bu yürütmeyi başlatan işlemin gaz fiyatı
• Bu yürütme için giriş verileri
• Geçerli yürütmenin bir parçası olarak bu hesaba iletilen değer (Wei cinsinden)
• Yürütülecek makine kodu
• Geçerli bloğun blok başlığı
• Mevcut mesaj çağrısının veya sözleşme oluşturma yığınının derinliği

Yürütmenin başlangıcında, bellek ve yığın boştur ve program sayacı sıfırdır.

PC: 0 STACK: [] MEM: [], STORAGE: {}

EVM daha sonra işlemi yinelemeli olarak yürütür ve her döngü için sistem durumunu ve makine durumunu hesaplar. Sistem durumu, basitçe Ethereum’un küresel durumudur. Makine durumu şunlardan oluşur:

• mevcut gaz(gas available)
• program sayıcı(program counter)
• hafıza içeriği(memory contents)
• hafızadaki aktif kelime sayısı(active number of words in memory)
• yığın içeriği(stack contents).

Yığın öğeleri, dizinin en sol kısmından eklenir veya çıkarılır.

Her çevrimde, kalan gazdan uygun gaz miktarı azaltılır ve program sayacı artar.

Her döngünün sonunda üç olasılık vardır:

1. Makine istisnai bir duruma ulaşır (örn. yetersiz gaz, geçersiz talimatlar, yetersiz yığın öğeleri, yığın öğeleri 1024'ün üzerine taşar, geçersiz JUMP/JUMPI hedefi vb.) ve bu nedenle, tüm değişiklikler atılarak durdurulmalıdır.
2. Sıra bir sonraki döngüde işlemeye devam eder
3. Makine kontrollü bir duruşa ulaşır (yürütme sürecinin sonu)

Yürütmenin istisnai bir duruma gelmediğini ve “kontrollü” veya normal bir durma noktasına ulaştığını varsayarsak, makine, sonuç durumunu, bu yürütmeden sonra kalan gazı, tahakkuk eden alt durumu ve ortaya çıkan çıktıyı üretir.

Vay canına. Ethereum’un en karmaşık kısımlarından birinden geçtik. Bu kısmı tam olarak anlamamış olsanız bile, sorun değil. Çok derin bir düzeyde çalışmadığınız sürece, gerçekten cesur yürütme ayrıntılarını anlamanıza gerek yoktur .

Bir blok nasıl sonuçlandırılır?

Son olarak, birçok işlem bloğunun nasıl sonuçlandırıldığına bakalım.

“Kesinleşmiş” dediğimizde, bloğun yeni veya mevcut olmasına bağlı olarak iki farklı anlama gelebilir. Eğer bu yeni bir blok ise, bu bloğun madenciliği için gereken süreçten bahsediyoruz. Mevcut bir bloksa, bloğu doğrulama sürecinden bahsediyoruz. Her iki durumda da, bir bloğun “sonlandırılmış” olması için dört gereklilik vardır:

1) Ommer’leri doğrulayın (veya madencilik yapıyorsanız belirleyin)

Blok başlığındaki her bir ommer bloğu geçerli bir başlık olmalı ve mevcut altıncı nesil içinde olmalıdır. engellemek.

2) İşlemleri doğrulayın (veya madencilik yapıyorsanız belirleyin)

Bloktaki gasUsed numarası, blokta listelenen işlemlerde kullanılan kümülatif gaza eşit olmalıdır. (Bir işlem gerçekleştirirken, bloktaki tüm işlemler tarafından kullanılan toplam gazı takip eden blok gaz sayacını takip ettiğimizi hatırlayın).

3) Ödülleri uygulayın (yalnızca madenciler yapabilir)

Hak sahibi adrese(beneficiary address) blok madenciliği için 5 Ether verilir. (Ethereum teklifi EIP-649 kapsamında , 5 ETH’lik bu ödül yakında 3 ETH’ye düşürülecek). Ek olarak, her ommer için, mevcut bloğun hak sahibine, mevcut blok ödülünün 1/32'si ek olarak verilir. Son olarak, ommer blok(lar)ının hak sahibine de belirli bir miktar verilir (bunun nasıl hesaplandığına dair özel bir formül vardır).

4) Durumu ve nonce’yi doğrulayın (veya madencilik yapıyorsanız geçerli olarak hesaplayın)

Tüm işlemlerin ve sonuçta ortaya çıkan durum değişikliklerinin uygulandığından emin olun ve ardından yeni bloğu, blok ödülü nihai işlemin sonuç durumuna uygulandıktan sonraki durum olarak tanımlayın. Doğrulama, başlıkta depolanan durum denemesine karşı bu son durumu kontrol ederek gerçekleşir.

Madencilik iş kanıtı

“ Bloklar ” bölümü kısaca blok zorluğu kavramına değindi. Engelleme zorluğunu anlamlandıran algoritmaya İş Kanıtı (PoW) denir.

Ethereum’un iş kanıtı algoritmasına “ Ethash ” (önceden Dagger-Hashimoto olarak biliniyordu) denir.

Algoritma resmi olarak şu şekilde tanımlanır:

Burada m , mixHashdir , n noncedur , Hn yeni bloğun başlığıdır ( hesaplanması gereken nonce ve mixHash bileşenleri hariç), Hn(soldaki) , blok başlığının nonce’sidir ve d büyük bir veri setidir.

“ Bloklar ” bölümünde, bir blok başlığında bulunan çeşitli öğelerden bahsettik. Bu bileşenlerden ikisi mixHash ve nonce olarak adlandırıldı . Hatırlayacağınız gibi:

• mixHash , nonce ile birleştirildiğinde bu bloğun yeterli hesaplama yaptığını kanıtlayan bir karmadır.
• nonce , mixHash ile birleştirildiğinde bu bloğun yeterli hesaplama yaptığını kanıtlayan bir karmadır.

PoW işlevi bu iki öğeyi değerlendirmek için kullanılır.

PoW işlevi kullanılarak mixHash ve nonce’nin tam olarak nasıl hesaplandığı biraz karmaşık ve ayrı bir gönderide daha derine inebileceğimiz bir şey. Ancak hatırlayacağınız üzere şöyle çalışır:

Her blok için bir “tohum” hesaplanır. Bu tohum, her çağın 30.000 blok uzunluğunda olduğu her “çağ” için farklıdır. İlk dönem için, tohum, 32 baytlık bir dizi sıfırın karma değeridir. Sonraki her dönem için, önceki tohum karmasının karma değeridir. Bu çekirdeği kullanarak, bir düğüm sözde rastgele bir “önbellek” hesaplayabilir.

Bu önbellek, bu gönderide daha önce tartıştığımız “hafif düğümler” kavramını mümkün kıldığı için inanılmaz derecede kullanışlıdır. Hafif düğümlerin amacı, belirli düğümlere, tüm blok zinciri veri setini depolama yükü olmadan bir işlemi verimli bir şekilde doğrulama yeteneği kazandırmaktır. Bir ışık düğümü, yalnızca bu önbelleğe dayalı bir işlemin geçerliliğini doğrulayabilir, çünkü önbellek, doğrulaması gereken belirli bloğu yeniden oluşturabilir.

Bir düğüm, önbelleği kullanarak, veri kümesindeki her öğenin önbellekten az sayıda sözde rastgele seçilmiş öğeye bağlı olduğu DAG “veri kümesini” oluşturabilir. Madenci olmak için bu tam veri setini oluşturmalısınız; tüm tam istemciler ve madenciler bu veri kümesini depolar ve veri kümesi zamanla doğrusal olarak büyür.

Madenciler daha sonra veri kümesinden rastgele dilimler alabilir ve bunları bir “mixHash” halinde bir araya getirmek için matematiksel bir işlevden geçirebilir. Bir madenci , çıktı istenen hedef nonce’nin altına düşene kadar art arda bir mixHash üretecektir . Çıktı bu gereksinimi karşıladığında, bu nonce geçerli kabul edilir ve blok zincire eklenebilir.

Bir güvenlik mekanizması olarak madencilik

Genel olarak, PoW’nin amacı, kriptografik olarak güvenli bir şekilde, bir miktar çıktı (yani nonce ) üretmek için belirli bir hesaplama miktarının harcandığını kanıtlamaktır. Bunun nedeni, tüm olasılıkları sıralamaktan başka, gerekli eşiğin altında olan bir nonce bulmanın daha iyi bir yolu olmamasıdır. Karma işlevinin tekrar tekrar uygulanmasının çıktıları tek tip bir dağılıma sahiptir ve bu nedenle ortalama olarak böyle bir nonce bulmak için gereken sürenin zorluk eşiğine bağlı olduğundan emin olabiliriz. Zorluk ne kadar yüksekse, nonce için çözmek o kadar uzun sürer. Bu şekilde PoW algoritması, blok zinciri güvenliğini zorlamak için kullanılan zorluk kavramına anlam kazandırmaktadır.

Blockchain güvenliği ile ne demek istiyoruz? Çok basit: HERKESİN güvendiği bir blok zinciri oluşturmak istiyoruz. Bu gönderide daha önce tartıştığımız gibi, birden fazla zincir mevcut olsaydı, kullanıcılar hangi zincirin “geçerli” zincir olduğunu makul bir şekilde belirleyemeyecekleri için güvenini kaybederdi. Bir grup kullanıcının bir blok zincirinde depolanan temel durumu kabul etmesi için, bir grup insanın inandığı tek bir kurallı blok zincirine ihtiyacımız var.

PoW algoritmasının yaptığı tam olarak budur: Belirli bir blok zincirinin gelecekte kabul edilir kalmasını sağlar ve bir saldırganın geçmişin belirli bir bölümünün üzerine yazan yeni bloklar oluşturmasını inanılmaz derecede zorlaştırır (örneğin işlemleri silerek veya sahte işlemler oluşturarak) veya çatallanmaya karşı korur. Önce bloklarının doğrulanması için, bir saldırganın nonce’yi ağdaki herkesten daha hızlı çözmesi gerekir, öyle ki ağ kendi zincirinin en ağır zincir olduğuna inanır (daha önce bahsettiğimiz GHOST protokolünün ilkelerine dayanarak). Saldırganın ağ madenciliği gücünün yarısından fazlasına sahip olmadıkça bu imkansız olurdu, bu senaryo çoğunluk %51 saldırısı olarak bilinir .

Bir servet dağıtım mekanizması olarak madencilik

PoW, güvenli bir blok zinciri sağlamanın ötesinde, bu güvenliği sağlamak için hesaplamalarını harcayanlara servet dağıtmanın bir yoludur. Bir madencinin bir blok madenciliği için aşağıdakileri içeren bir ödül aldığını hatırlayın:

• “kazanan” blok için 5 eter statik blok ödülü
• bloğa dahil olan işlemlerle blok içinde harcanan gazın maliyeti
• Ommer’ları bloğun bir parçası olarak dahil etmek için ekstra bir ödül

PoW konsensüs mekanizmasının güvenlik ve servet dağıtımı için kullanımının uzun vadede sürdürülebilir olmasını sağlamak için Ethereum bu iki özelliği aşılamaya çalışır:

• Mümkün olduğunca çok insan için erişilebilir hale getirin. Başka bir deyişle, insanların algoritmayı çalıştırmak için özel veya yaygın olmayan donanımlara ihtiyacı olmamalıdır. Bunun amacı, servet dağıtım modelini mümkün olduğunca açık hale getirmektir, böylece herkes Ether karşılığında herhangi bir miktarda hesaplama gücü sağlayabilir.
• Herhangi bir tek düğümün (veya küçük kümenin) orantısız miktarda kâr elde etme olasılığını azaltın. Orantısız miktarda kar yapabilen herhangi bir düğüm, düğümün herkes tarafından kabul edilen blok zincirini belirlemede büyük bir etkiye sahip olduğu anlamına gelir. Bu, ağ güvenliğini azalttığı için zahmetlidir.

Bitcoin blok zinciri ağında, yukarıdaki iki özellikle ilgili olarak ortaya çıkan bir sorun, PoW algoritmasının bir SHA256 karma işlevi olmasıdır. Bu tür bir işlevin zayıf yanı, ASIC olarak da bilinen özel donanım kullanılarak çok daha verimli bir şekilde çözülebilmesidir.

Bu sorunu azaltmak için Ethereum, PoW algoritmasını ( Ethhash ) sıralı olarak belleğe dayanıklı hale getirmeyi seçti. Bu, algoritmanın, nonce’yi hesaplamak için çok fazla bellek VE bant genişliği gerektirecek şekilde tasarlandığı anlamına gelir. Büyük bellek gereksinimleri, bir bilgisayarın aynı anda birden çok nonce keşfetmek için belleğini paralel olarak kullanmasını zorlaştırır ve yüksek bant genişliği gereksinimleri süper hızlı bir bilgisayarın bile aynı anda birden çok nonce bulmasını zorlaştırır. Bu, merkezileşme riskini azaltır ve doğrulamayı yapan düğümler için daha eşit bir oyun alanı yaratır.

Unutulmaması gereken bir şey, Ethereum’un bir PoW konsensüs mekanizmasından “hisse kanıtı” adı verilen bir şeye geçiş yapmasıdır. Bu, gelecekteki bir gönderide umarız keşfedebileceğimiz, kendi başına canavarca bir konudur. ☺️

Çözüm

…Vay canına! Sen sonuna kadar yaptın. Umarım?

Bu yazıda sindirilecek çok şey var, biliyorum. Neler olup bittiğini tam olarak anlamak için birden fazla okuma yapmanız gerekiyorsa, bu tamamen sorun değil. Neler olup bittiğine bakmadan önce Ethereum sarı kağıdını, beyaz kağıdı ve kod tabanının çeşitli kısımlarını kişisel olarak birçok kez okudum.

Yine de, umarım bu genel bakışı yararlı bulmuşsunuzdur. Herhangi bir hata veya hata bulursanız, özel bir not yazmanızı veya doğrudan yorumlara göndermenizi isterim. Hepsine bakıyorum söz veriyorum ;)

Ve unutmayın, ben insanım (evet, bu doğru) ve hatalar yaparım. Bu yazıyı topluluğun yararına ücretsiz olarak yazmak için zaman ayırdım. Bu yüzden lütfen gereksiz yere kırmadan geri bildiriminizde yapıcı olun.