Bir blok zinciri oluşturan veri yapılarını anlamak, bu verileri ayrıştırmanın yaratıcı yollarını düşünmemize yardımcı olur.
**Yazan:**NOXX
Derleme: Temizle
Zincir verilerde gezinmek, Web3 alanını anlamak isteyen herkes için temel bir beceridir. Bir blok zinciri oluşturan veri yapılarını anlamak, bu verileri ayrıştırmanın yaratıcı yollarını düşünmemize yardımcı olur. Aynı zamanda bu zincir üstü veriler, mevcut verilerin büyük bir bölümünü oluşturmaktadır. Bu gönderi, EVM'deki önemli bir veri yapısını, işlem makbuzunu ve bununla ilişkili olay günlüğünü inceleyecektir.
Neden günlük
Başlamadan önce bir solidity geliştiricisi olarak neden event log kullanmamız gerektiğinden kısaca bahsedelim:
Olay günlüğü, sözleşme tarafından erişilmesi gerekmeyen veri depolama için daha ucuz bir seçenektir ve ayrıca akıllı sözleşmedeki belirli değişkenleri test ederek, değişkenleri indeksleyerek saklanan durumu yeniden yapılandırabilir.
Olay günlüğü, belirli bir olay günlüğünü dinleyen bir Web3 uygulamasını tetiklemenin bir yoludur.
EVM düğümlerinin günlükleri sonsuza kadar tutması gerekmez ve eski günlükleri silerek yerden tasarruf edebilir. Sözleşmelerin günlük depolamaya erişimi yoktur, bu nedenle düğümlerin sözleşmeleri yürütmek için bunlara ihtiyacı yoktur. Sözleşme depolaması ise yürütme için gereklidir ve bu nedenle silinemez.
Ethereum Blok Merkle Kökü
Bölümde, Ethereum çerçevesini, özellikle de durum Merkle kök kısmını inceledik. Durum Kökü, blok başlığında yer alan üç Merkle kökünden biridir. Diğer ikisi İşlem Kökü ve Makbuz Köküdür.
Bu çerçeveyi oluşturmaya girdi olarak, ilgili makbuzlar ve gönderilen olay günlükleriyle birlikte 5 işlem içeren Ethereum'daki 15001871 bloğuna bakacağız.
blok başlığı
Blok başlığında Transaction Root, Receipt Root ve Logs Bloom olmak üzere 3 kısım ile başlayacağız (blok başlığına kısa bir giriş Bölüm 4'te incelenebilir).
Kaynak:
İşlem Kökü ve Makbuz Kökü altındaki Ethereum istemcisinde, Merkle Patricia Tries, bloktaki tüm işlem verilerini ve makbuz verilerini içerir. Bu makale yalnızca bir düğümün erişebileceği tüm işlemlere ve makbuzlara odaklanacaktır.
Ethereum düğümü aracılığıyla bulunan 15001871 bloğunun blok başlık bilgisi aşağıdaki gibidir:
Blok başlığındaki logsBloom, bu makalenin ilerleyen kısımlarında bahsedilecek olan bir anahtar veri yapısıdır. Öncelikle Transaction Root yani Transaction Trie altında yer alan data ile başlayalım.
İşlem Ağacı İşlem Trie
İşlem Trie, işlem kökü oluşturan ve işlem istek vektörlerini kaydeden bir veri kümesidir. İşlem istek vektörleri, bir işlemi gerçekleştirmek için gerekli bilgi parçalarıdır. Bir işlemde yer alan veri alanları aşağıdaki gibidir:
Tür - işlem türü (LegacyTxType geleneksel işlem, AccessListTxType EIP-2930 tanıtımı, DynamicFeeTxType EIP-1559 tanıtımı)
ChainId - İşlemin EIP155 zincir kimliği
Veri - işlemin giriş verileri
AccessList - işlemler için erişim listesi
Gas - işlemin gas limiti
GasPrice - işlemin gaz fiyatı
GasTipCap - işlem birimi gazı ilk paketlemek için temel ücreti aşan madenciler için teşvik primi, Geth'te maxPriorityFeePerGas EIP1559 tarafından tanımlanır
GasFeeCap - işlem birimi başına gas ücretinin üst sınırı, Geth'teki maxFeePerGas (GasFeeCap ≥ baseFee + GasTipCap)
Değer - işlem gören Ethereum miktarı
Nonce - ticaret hesabını oluşturan kişinin nonce'si
Kime - İşlemin alıcı adresi. Sözleşme oluşturma işlemleri için To, sıfır değeri döndürür
RawSignaturues - İşlem verilerinin imza değerleri V, R, S
Yukarıdaki veri alanlarını anladıktan sonra 15001871 bloğunun ilk işlemine bir göz atalım.
Geth'in ethclient sorgusu aracılığıyla, hem ChainId hem de AccessList'in "omitempty"ye sahip olduğunu görebilirsiniz; bu, alan boşsa, seri hale getirilmiş verilerin boyutunu küçültmek veya kısaltmak için yanıtta çıkarılacağı anlamına gelir.
kod kaynağı:
Bu işlem, USDT tokenlerinin 0xec23e787ea25230f74a3da0f515825c1d820f47a adresine transferini temsil eder. Kime adresi, ERC20 USDT sözleşme adresidir 0xdac17f958d2ee523a2206206994597c13d831ec7. GİRİŞ VERİLERİ aracılığıyla, 0xa9059cbb işlev imzasının Transfer (Adres, UINT256) işlevine karşılık geldiğini ve 42.251 USDT'nin (doğruluk 6) 0x2b279b8'e (45251000) 0xEC23E787EA25230F'den 0xEC23E787EA25230F'ye aktarıldığını görebiliriz. 3DA0F515825C1D820F47A adresi.
Bu işlem veri yapısının bize işlemin sonucu hakkında hiçbir şey söylemediğini fark etmiş olabilirsiniz, bu durumda işlem başarılı oldu mu? Ne kadar gaz tüketir? Hangi olay kayıtları tetiklenir? Bu noktada Makbuz Trie'yi tanıtacağız.
Makbuz Trie
Tıpkı bir alışveriş fişinin bir işlemin sonucunu kaydetmesi gibi, Makbuz Trie'deki bir nesne de Ethereum işlemi için aynısını yapar ancak bazı ek ayrıntıları da kaydeder. Yukarıdaki işlem makbuzlarıyla ilgili soruyu sormaya dönersek, aşağıdaki olayları tetikleyen günlüklere odaklanacağız.
0x311b'nin on-chain verilerini tekrar sorgulayın ve işlem fişini alın.Bu sırada aşağıdaki alanlar elde edilecektir:
kod kaynağı:
Tür - işlem türü (LegacyTxType, AccessListTxType, DynamicFeeTxType)
PostState(root) - StateRoot, işlem gerçekleştirildikten sonra oluşturulan durum ağacının kök düğümü, şekilde bulunan karşılık gelen değer 0x'tir, muhtemelen EIP98 nedeniyle
CumulativeGasUsed - Bu işlem ve aynı blokta önceki tüm işlemler tarafından tüketilen kümülatif toplam Gas
Bloom(logsBloom) - Blok zincirindeki sözleşme olay günlüklerini verimli bir şekilde aramak ve bunlara erişmek için kullanılan olay günlükleri için Bloom filtresi, düğümlerin bloğu tamamen ayrıştırmadan bir blokta belirli bir olayın meydana gelip gelmediğini hızlı bir şekilde almasını sağlar Bloktaki tüm işlem makbuzları
Günlükler - işlem yürütme sırasında tetiklenen sözleşme olayları tarafından oluşturulan günlük girişlerini içeren bir günlük nesneleri dizisi
TxHash - makbuzla ilişkili işlem karması
SözleşmeAdresi - İşlem bir sözleşme oluşturmaksa, sözleşmenin dağıtıldığı adres. İşlem bir sözleşme oluşturma değilse, ancak bir aktarım veya konuşlandırılmış bir akıllı sözleşmeyle etkileşim gibiyse, SözleşmeAdresi alanı boş olacaktır.
GasUsed - bu işlem tarafından tüketilen gaz
BlockNumber - bu işlemin gerçekleştiği bloğun blok numarası
TransactionIndex - Blok içindeki işlem dizini, dizin hangi işlemin önce yürütüleceğini belirler. Bu işlem bloğun en üstündedir, bu nedenle dizin 0
Artık işlem fişinin yapısını öğrendiğimize göre, işlem fişindeki logsBloom ve günlük dizisi günlüklerine daha yakından bakalım.
Olay Günlükleri
Ethereum ana ağındaki USDT sözleşme kodu aracılığıyla, Transfer olayının sözleşmenin 86. satırında bildirildiğini ve iki giriş parametresinin "indexed" anahtar sözcüğüne sahip olduğunu görebiliriz.
(kod kaynağı:
Bir olay girişi "dizine eklendiğinde", bu giriş aracılığıyla günlükleri hızlı bir şekilde bulmamızı sağlar. Örneğin, yukarıdaki "from" dizinini kullanırken, X ve Y blokları arasında 0x5041ed759dd4afc3a72b8192c143f72f4724081a "from" adresli Transfer türündeki tüm olay günlüklerini almak mümkündür. 138. satırda transfer fonksiyonu çağrıldığında olay günlüğünün ateşlendiğini de görebiliriz. Mevcut sözleşmenin daha eski bir sağlamlık sürümünü kullandığını belirtmekte fayda var, bu nedenle emit anahtar sözcüğü eksik.
Elde edilen zincir üstü verilere geri dönün:
kod kaynağı:
Adresi, konuları ve veri alanlarını biraz daha derinlemesine inceleyelim.
Tema Konuları
Konular bir dizin değeridir. Yukarıdaki şekilden, zincirdeki sorgu verilerinde konuların 3 indeks parametresi olduğunu, Transfer olayında ise sadece 2 indeks parametresinin (from ve to) olduğunu görebiliriz. Bunun nedeni, ilk konunun her zaman olayın işlev imza karması olmasıdır. Geçerli örnekteki olay işlevi imzası şöyledir: Transfer(address, address, uint256). Keccak256 ile hash yaparak ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef sonucunu elde ederiz.
(Çevrimiçi araç:
From alanını yukarıda bahsettiğimiz gibi sorguladığımızda ancak aynı zamanda sorgu event log tipini sadece Transfer tipi event logları ile sınırlamak istediğimizde, event imzalarını indeksleyerek event tipine göre filtreleme yapmamız gerekmektedir.
En fazla 4 konuya sahip olabiliriz, her konunun boyutu 32 bayttır (index parametresinin türü 32 bayttan büyükse (yani, dize ve bayt), gerçek veriler saklanmaz, ancak verilerin bir keccak256 özeti depolanır. saklanır). İlk parametre event imzası tarafından alındığı için 3 index parametresi bildirebiliriz. Ancak, ilk konunun bir karma olay imzası olmadığı bir durum var. Anonim olayları bildirirken durum budur. Bu, önceki 3 yerine 4 indeks parametresi kullanma olasılığını açar, ancak olay adlarını indeksleme yeteneğini kaybeder. Anonim etkinliklerin diğer bir avantajı da, ek bir konuyu zorunlu kılmadıkları için dağıtılmalarının daha ucuz olmasıdır. Diğer konu ise Transfer olayından "from" ve "to" indexlerinin değerleridir.
VeriVerileri
Veri bölümü, olay günlüğünden kalan (dizinlenmemiş) parametreleri içerir. Yukarıdaki örnekte, ondalık basamakta 45251000 olan 0x0000000000000000000000000000000000000000000000000000000000002b279b8 bir değer vardır, bu da yukarıda belirtilen 45.251 $ tutarındadır. Bu tür daha fazla parametre varsa, bunlar veri öğesine eklenir. Aşağıdaki örnek, 1'den fazla indekslenmemiş parametre durumunu gösterecektir.
Mevcut örnek, Transfer olayına fazladan bir "vergi" alanı ekler. Ayarlanan verginin %20 olduğunu varsayalım, ardından vergi değeri 45251000 * %20 = 9050200 olmalı, onaltılık değeri 0x8a1858, çünkü bu sayının türü uint256 ve veri türü 32 bayt, ihtiyacınız var onaltılık değer 32 bayt ile doldurulur ve veri öğesinin sonucu 0x0000000000000000000000000000000000000000000000000000002b279b800000000000000000000000000000000 0000 00000000000000000000008a1858.
Adres
Adres alanı, olayı yayınlayan sözleşmenin adresidir, bu alanla ilgili önemli bir not, konu bölümünde yer almasa bile dizine eklenecektir. Bunun nedeni, Transfer olayının ERC20 standardının bir parçası olmasıdır, yani ERC20 transfer olaylarının günlüklerini filtrelemek gerektiğinde, transfer olayları tüm ERC20 sözleşmelerinden elde edilecektir. Ve sözleşme adresini endeksleyerek, arama, örnekteki USDT gibi belirli bir sözleşmeye/token'a kadar daraltılabilir.
İşlem Kodları İşlem Kodları
Son olarak LOG işlem kodu var. Hiçbir konu olmadığında LOG0'dan 4 konu olduğunda LOG4'e kadar değişir. LOG3, örneğimizde kullandığımız şeydir. Aşağıdakileri içerir:
ofset - veri alanı girişinin başlangıç konumunu gösteren bellek ofseti
uzunluk - bellekten okunacak verinin uzunluğu
x konusu(0 - 4) - x konusunun değeri
(Kaynak:
ofset ve uzunluk, verilerin bellekteki veri bölümünde nerede bulunduğunu tanımlar.
Günlüğün yapısını ve bir konunun nasıl dizine eklendiğini anladıktan sonra, dizin öğelerinin nasıl arandığını anlayalım.
Bloom Filtreleri Bloom Filtreleri
Öğelerin daha hızlı aranmasını indekslemenin sırrı Bloom filtresidir.
Llimllib makalesi, bu veri yapısının iyi bir tanımına ve açıklamasına sahiptir.
"Bloom filtresi, bir öğenin bir koleksiyonda olup olmadığını belirlemek için kullanılabilen bir veri yapısıdır. Hızlı çalışma ve küçük bellek alanı özelliklerine sahiptir. Verimli ekleme ve sorgulamanın maliyeti, Bloom Filtresinin olasılık tabanlı bir veri olmasıdır. yapı: Bize yalnızca bir öğenin kesinlikle kümede olmadığını veya muhtemelen kümede olmadığını söyleyebilir.Bloom filtresinin altında yatan veri yapısı bir bit vektörüdür.
Aşağıda bir bit vektörü örneği verilmiştir. Beyaz hücreler, 0 değerine sahip bitleri ve yeşil hücreler, 1 değerine sahip bitleri temsil eder.
Bu bitler, bir miktar girdi alınarak ve hash edilerek 1'e ayarlanır, elde edilen hash değeri, bitin güncellenmesi gereken bir bit dizini olarak kullanılır. Yukarıdaki bit vektörü, 2 bitlik bir dizin elde etmek için "ethereum" değerine 2 farklı karma uygulamanın sonucudur. Karma, onaltılık bir sayıyı temsil eder ve dizini elde etmek için sayıyı alıp 0 ile 14 arasında bir değere dönüştürürsünüz. Mod 14 gibi bunu yapmanın birçok yolu vardır.
Gözden geçirmek
İşlemler için bir Bloom filtresiyle, yani bir bit vektörüyle, bit vektöründeki hangi bitlerin güncelleneceğini belirlemek için Ethereum'da karma yapılabilir.Giriş, adres alanı ve olay günlüğünün konusudur. İşleme özel bir Bloom filtresi olan işlem fişindeki logsBloom'u inceleyelim. Bir işlem, tüm günlüklerin adresini / konusunu içeren birden fazla günlük içerebilir.
Blok başlığına geri bakarsanız, başka bir logsBloom bulacaksınız. Bu, blok içindeki tüm işlemler için bir Bloom filtresidir. Her işlem için her günlükteki tüm adresleri/konuları içerir.
Bu Bloom filtreleri ikili değil onaltılık olarak ifade edilir. 256 bayt uzunluğundadırlar ve 2048 bitlik bir vektörü temsil ederler. Yukarıdaki Llimllib örneğine bakarsak, bit vektör uzunluğumuz 15'tir ve bit indeksleri 2 ve 13, 1 olarak çevrilir. Bakalım bunu hex'e çevirdiğimizde ne elde edeceğiz.
Onaltılık gösterim bir bit vektörü gibi görünmese de logsBloom'da öyledir.
Sorgu Sorguları
Daha önce "Kimden" adresi 0x5041ed759dd4afc3a72b8192c143f72f4724081a olan Transfer türünün X ve Y blokları arasındaki tüm olay günlüklerini bul" şeklinde bir sorgudan bahsedilmişti. Transfer türünde bir konuyu temsil eden event imza konusunu ve from (0x5041…) değerini alabilir ve Bloom filtresinde hangi bit indekslerinin 1 yapılması gerektiğini belirleyebiliriz.
Blok başlığında logsBloom kullanırsanız, bu bitlerden herhangi birinin 1'e ayarlanıp ayarlanmadığını kontrol edebilirsiniz. Değilse, blokta koşulla eşleşen günlük olmadığı belirlenebilir. Ve bu bitlerin ayarlanmış olduğu bulunursa, eşleşen bir günlüğün muhtemelen blokta olduğunu biliyoruz. Ancak tam olarak emin değilim çünkü logsBloom blok başlığı birden fazla adres ve konudan oluşuyor. Diğer olay günlüklerinde eşleştirme bitleri ayarlanmış olabilir. Bu nedenle bir Bloom filtresi olasılıksal bir veri yapısıdır. Bit vektörü ne kadar büyük olursa, diğer günlüklerle bit dizini çakışmalarının meydana gelme olasılığı o kadar az olur. Eşleşen bir Bloom filtreniz olduğunda, logsBloom'u tek tek makbuzlar için sorgulamak için aynı yöntemi kullanabilirsiniz. Bir eşleşme elde edildiğinde, nesneyi almak için gerçek günlük girişi görüntülenebilir.
Kriterleri karşılayan tüm günlükleri hızlı bir şekilde bulmak ve almak için X'ten Y'ye kadar olan bloklarda yukarıdaki işlemleri yürütün. Bloom filtresi kavramsal olarak bu şekilde çalışır.
Şimdi Ethereum'da kullanılan uygulamaya bakalım.
Geth uygulaması - Bloom Filtreleri
Artık Bloom filtresinin nasıl çalıştığını öğrendiğimize göre, Bloom filtresinin gerçek bir blokta adres / konudan logsBloom'a kadar adım adım taramayı nasıl tamamladığını öğrenelim.
Öncelikle Ethereum Yellow Paper'ın tanımından:
Kaynak:
"Günlük girişlerini tek bir 256 baytlık hash'e indirgeyen bir Bloom filtre işlevi M tanımlıyoruz:
içinde keyfi bir bayt dizisi verildiğinde 2048'de üç bit ayarlayan özel bir Bloom filtresidir. Bu, bayt dizisinin Keccak-256 hash'indeki ilk üç bayt çiftinin her birinin alt 11 biti alınarak yapılır. "
Yukarıdaki tanımların anlaşılmasını basitleştirmek için aşağıda bir Geth istemci uygulamasına ilişkin bir örnek ve referans verilmiştir.
İşte Etherscan'de incelediğimiz işlem günlüğü.
İlk konu 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef olay imzasıdır ve bu değeri güncellenmesi gereken bit dizinine dönüştürür.
Geth kod tabanından bloomValues fonksiyonu aşağıdadır.
Bu işlev, 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef gibi olay imza konusunu ve diğer verileri alır ve Bloom filtresinde güncellenmesi gereken bit dizinini döndürür.
kod kaynağı:
bloomValues işlevi, girdi olarak bir konu (örnekte olay imzası) ve bir hashbuf (6 uzunluğunda boş bir bayt dizisi) alır.
Sarı Kağıt parçacığına bakın, "Bir bayt dizisinin Keccak-256 karmasındaki ilk üç çift bayt". Bu üç bayt çifti, hashbuf'un uzunluğu olan 6 bayttır.
Örnek veriler: 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef.
140 - 144. satırlar arasındaki sha komutu giriş verilerini özetler ve çıktıyı hashbuf'a yükler.
keccak256 kullanılarak sha çıktısının onaltılık sonucu şu şekildedir (işlev imzası olarak keccak 256 kullanıldığında, giriş metin türündedir, ancak burada onaltılık türdedir): ada389e1fc24a8587c776340efb91b36e675792ab631816100d55df0b5cf3cbc.
Mevcut hasbuf içeriği [ad, a3, 89, e1, fc, 24] (onaltılık). Her onaltılık karakter 4 biti temsil eder.
Bir bayt 8 bitten oluşur.Bir bit indeksi almak istiyorsanız, elde edilen değerin sıfır indeks dizisinin 0 ile 7 arasında olduğundan emin olmanız gerekir. Hashbuf için bit düzeyinde AND kullanın [1] 0 ile 7 arasındaki değerlerle sınırlıdır. Örnekte hesaplanmıştır, 10100011 & 00000111 = 00000011 = 3.
Bu bit dizini değeri, bir ters çevrilmiş bit oluşturmak için bir bit kaydırma operatörüyle, yani 3 bit sola kaydırılarak 8 bitlik bayt dizini 00001000 ile sonuçlanır.
v1, gerçek bit dizini yerine tüm bayttır, çünkü bu değer daha sonra Bloom filtresinde bit düzeyinde VEYA'ya tabi tutulacaktır. VEYA işlemi, Bloom filtresindeki karşılık gelen tüm bitlerin de çevrilmesini sağlayacaktır.
Artık bayt değerlerimiz var, ancak yine de bayt dizinlerine ihtiyacımız var. Bloom filtresi 256 bayt uzunluğundadır (2048 bit), bu nedenle hangi baytın bit düzeyinde OR üzerinde çalıştırılacağını bilmemiz gerekir. i1 değeri bu bayt dizinini temsil eder.
Hashbuf'u, örnekte 0xada3 = 1010110110100011 olan bit dizisinin ilk 2 baytını sınırlamasını sağlayan big-endian uint16 bayt sırasına göre koyun.
Bitsel VE bu değer 0x7ff = 0000011111111111 ile. 0x7ff'nin 1'e ayarlandığı 11 bit vardır. Sarı kağıtta belirtildiği gibi, "bunu ilk üç çiftin her birinin alt 11 bitini alarak yapar". Bu, 1010110110100011 ve 0000011111111111 olan 0000010110100011 değeriyle sonuçlanacaktır.
Ardından değeri 3 bit sağa kaydırın. Bu, 11 basamaklı bir sayıyı 8 basamaklı bir sayıya dönüştürür. Bir bayt dizini istiyoruz ve Bloom filtresinin bayt uzunluğu 256, bu nedenle bayt dizin değerinin bu aralıkta olması gerekiyor. Ve 8 bitlik bir sayı, 0 ile 255 arasında herhangi bir değer olabilir. Örneğimizde bu değer 0000010110100011 3 bit sağa kaydırılmıştır 10110100 = 180.
256 eksi hesaplanan 180 eksi 1 olduğunu bilerek bayt dizinimizi BloomByteLength ile hesaplayın. Sonucu 0 ile 255 arasında tutmak için 1 çıkarın. Bu bize güncellenecek bayt dizinini verir, bu durumda bunun bayt 75 olduğu ortaya çıkar, i1'i bu şekilde hesapladık.
Bloom filtresinin 75. baytındaki bit dizini 3'ü güncelleyin (0, dizin yani 4. bittir), bu, Bloom filtresinin 75. baytında v1'in bit düzeyinde VEYA işlemini gerçekleştirerek yapılabilir.
Yalnızca ilk bayt çifti olan 0xada3'ü ele aldık, bu işlem yine 2 ve 3 numaralı bayt çiftleri için yapıldı. Her adres / konu, 2048 bit vektörde 3 bit güncelleyecektir. Sarı Kitapta bahsedildiği gibi, "Bloom filtresi, rasgele bir bayt dizisi verildiğinde 2048'de üç bit ayarlar".
Bayt çifti 2 durum güncellemeleri, bit dizini 1'i bayt 195'te günceller (3 ve 4 numaralı prosedürlere göre yürütün, sonuç şekilde gösterilmiştir).
Bayt 123'te Bayt çifti 3 durum güncelleme bit dizini 4.
Güncellenecek bit başka bir konu tarafından çevrilmişse, olduğu gibi kalacaktır. Olmazsa 1'e döner.
Yukarıdaki işlem sürecinde, olay imza konusunun Bloom filtresinde aşağıdaki bitleri çevireceği belirlenebilir:
Bayt 75'te bit dizini 3
bayt 195'te bit dizini 1
bayt 123'te bit dizini 4
İkiliye dönüştürülen işlem makbuzunda logBlooms'a bakıldığında, bu bit indekslerinin ayarlandığı doğrulanır.
Bu arada, günlük arama ve Bloom filtresinin uygulanması hakkında daha fazla bilgi edinmek isteyen okuyucular için BloomBits Trie makalesine başvurabilirsiniz.
Bu noktada, EVM serisi makalelerle ilgili derinlemesine tartışmamız sona erdi ve gelecekte daha yüksek kaliteli teknik makaleleri sizlerle buluşturacağız.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
EVM veri yapılarına, işlem makbuzlarına ve olay günlüklerine dalın
**Yazan:**NOXX
Derleme: Temizle
Zincir verilerde gezinmek, Web3 alanını anlamak isteyen herkes için temel bir beceridir. Bir blok zinciri oluşturan veri yapılarını anlamak, bu verileri ayrıştırmanın yaratıcı yollarını düşünmemize yardımcı olur. Aynı zamanda bu zincir üstü veriler, mevcut verilerin büyük bir bölümünü oluşturmaktadır. Bu gönderi, EVM'deki önemli bir veri yapısını, işlem makbuzunu ve bununla ilişkili olay günlüğünü inceleyecektir.
Neden günlük
Başlamadan önce bir solidity geliştiricisi olarak neden event log kullanmamız gerektiğinden kısaca bahsedelim:
EVM düğümlerinin günlükleri sonsuza kadar tutması gerekmez ve eski günlükleri silerek yerden tasarruf edebilir. Sözleşmelerin günlük depolamaya erişimi yoktur, bu nedenle düğümlerin sözleşmeleri yürütmek için bunlara ihtiyacı yoktur. Sözleşme depolaması ise yürütme için gereklidir ve bu nedenle silinemez.
Ethereum Blok Merkle Kökü
Bu çerçeveyi oluşturmaya girdi olarak, ilgili makbuzlar ve gönderilen olay günlükleriyle birlikte 5 işlem içeren Ethereum'daki 15001871 bloğuna bakacağız.
blok başlığı
Blok başlığında Transaction Root, Receipt Root ve Logs Bloom olmak üzere 3 kısım ile başlayacağız (blok başlığına kısa bir giriş Bölüm 4'te incelenebilir).
Kaynak:
İşlem Kökü ve Makbuz Kökü altındaki Ethereum istemcisinde, Merkle Patricia Tries, bloktaki tüm işlem verilerini ve makbuz verilerini içerir. Bu makale yalnızca bir düğümün erişebileceği tüm işlemlere ve makbuzlara odaklanacaktır.
Ethereum düğümü aracılığıyla bulunan 15001871 bloğunun blok başlık bilgisi aşağıdaki gibidir:
Blok başlığındaki logsBloom, bu makalenin ilerleyen kısımlarında bahsedilecek olan bir anahtar veri yapısıdır. Öncelikle Transaction Root yani Transaction Trie altında yer alan data ile başlayalım.
İşlem Ağacı İşlem Trie
İşlem Trie, işlem kökü oluşturan ve işlem istek vektörlerini kaydeden bir veri kümesidir. İşlem istek vektörleri, bir işlemi gerçekleştirmek için gerekli bilgi parçalarıdır. Bir işlemde yer alan veri alanları aşağıdaki gibidir:
Yukarıdaki veri alanlarını anladıktan sonra 15001871 bloğunun ilk işlemine bir göz atalım.
Geth'in ethclient sorgusu aracılığıyla, hem ChainId hem de AccessList'in "omitempty"ye sahip olduğunu görebilirsiniz; bu, alan boşsa, seri hale getirilmiş verilerin boyutunu küçültmek veya kısaltmak için yanıtta çıkarılacağı anlamına gelir.
kod kaynağı:
Bu işlem, USDT tokenlerinin 0xec23e787ea25230f74a3da0f515825c1d820f47a adresine transferini temsil eder. Kime adresi, ERC20 USDT sözleşme adresidir 0xdac17f958d2ee523a2206206994597c13d831ec7. GİRİŞ VERİLERİ aracılığıyla, 0xa9059cbb işlev imzasının Transfer (Adres, UINT256) işlevine karşılık geldiğini ve 42.251 USDT'nin (doğruluk 6) 0x2b279b8'e (45251000) 0xEC23E787EA25230F'den 0xEC23E787EA25230F'ye aktarıldığını görebiliriz. 3DA0F515825C1D820F47A adresi.
Bu işlem veri yapısının bize işlemin sonucu hakkında hiçbir şey söylemediğini fark etmiş olabilirsiniz, bu durumda işlem başarılı oldu mu? Ne kadar gaz tüketir? Hangi olay kayıtları tetiklenir? Bu noktada Makbuz Trie'yi tanıtacağız.
Makbuz Trie
Tıpkı bir alışveriş fişinin bir işlemin sonucunu kaydetmesi gibi, Makbuz Trie'deki bir nesne de Ethereum işlemi için aynısını yapar ancak bazı ek ayrıntıları da kaydeder. Yukarıdaki işlem makbuzlarıyla ilgili soruyu sormaya dönersek, aşağıdaki olayları tetikleyen günlüklere odaklanacağız.
0x311b'nin on-chain verilerini tekrar sorgulayın ve işlem fişini alın.Bu sırada aşağıdaki alanlar elde edilecektir:
kod kaynağı:
Artık işlem fişinin yapısını öğrendiğimize göre, işlem fişindeki logsBloom ve günlük dizisi günlüklerine daha yakından bakalım.
Olay Günlükleri
Ethereum ana ağındaki USDT sözleşme kodu aracılığıyla, Transfer olayının sözleşmenin 86. satırında bildirildiğini ve iki giriş parametresinin "indexed" anahtar sözcüğüne sahip olduğunu görebiliriz.
(kod kaynağı:
Bir olay girişi "dizine eklendiğinde", bu giriş aracılığıyla günlükleri hızlı bir şekilde bulmamızı sağlar. Örneğin, yukarıdaki "from" dizinini kullanırken, X ve Y blokları arasında 0x5041ed759dd4afc3a72b8192c143f72f4724081a "from" adresli Transfer türündeki tüm olay günlüklerini almak mümkündür. 138. satırda transfer fonksiyonu çağrıldığında olay günlüğünün ateşlendiğini de görebiliriz. Mevcut sözleşmenin daha eski bir sağlamlık sürümünü kullandığını belirtmekte fayda var, bu nedenle emit anahtar sözcüğü eksik.
Elde edilen zincir üstü verilere geri dönün:
kod kaynağı:
Adresi, konuları ve veri alanlarını biraz daha derinlemesine inceleyelim.
Tema Konuları
Konular bir dizin değeridir. Yukarıdaki şekilden, zincirdeki sorgu verilerinde konuların 3 indeks parametresi olduğunu, Transfer olayında ise sadece 2 indeks parametresinin (from ve to) olduğunu görebiliriz. Bunun nedeni, ilk konunun her zaman olayın işlev imza karması olmasıdır. Geçerli örnekteki olay işlevi imzası şöyledir: Transfer(address, address, uint256). Keccak256 ile hash yaparak ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef sonucunu elde ederiz.
(Çevrimiçi araç:
From alanını yukarıda bahsettiğimiz gibi sorguladığımızda ancak aynı zamanda sorgu event log tipini sadece Transfer tipi event logları ile sınırlamak istediğimizde, event imzalarını indeksleyerek event tipine göre filtreleme yapmamız gerekmektedir.
En fazla 4 konuya sahip olabiliriz, her konunun boyutu 32 bayttır (index parametresinin türü 32 bayttan büyükse (yani, dize ve bayt), gerçek veriler saklanmaz, ancak verilerin bir keccak256 özeti depolanır. saklanır). İlk parametre event imzası tarafından alındığı için 3 index parametresi bildirebiliriz. Ancak, ilk konunun bir karma olay imzası olmadığı bir durum var. Anonim olayları bildirirken durum budur. Bu, önceki 3 yerine 4 indeks parametresi kullanma olasılığını açar, ancak olay adlarını indeksleme yeteneğini kaybeder. Anonim etkinliklerin diğer bir avantajı da, ek bir konuyu zorunlu kılmadıkları için dağıtılmalarının daha ucuz olmasıdır. Diğer konu ise Transfer olayından "from" ve "to" indexlerinin değerleridir.
VeriVerileri
Veri bölümü, olay günlüğünden kalan (dizinlenmemiş) parametreleri içerir. Yukarıdaki örnekte, ondalık basamakta 45251000 olan 0x0000000000000000000000000000000000000000000000000000000000002b279b8 bir değer vardır, bu da yukarıda belirtilen 45.251 $ tutarındadır. Bu tür daha fazla parametre varsa, bunlar veri öğesine eklenir. Aşağıdaki örnek, 1'den fazla indekslenmemiş parametre durumunu gösterecektir.
Mevcut örnek, Transfer olayına fazladan bir "vergi" alanı ekler. Ayarlanan verginin %20 olduğunu varsayalım, ardından vergi değeri 45251000 * %20 = 9050200 olmalı, onaltılık değeri 0x8a1858, çünkü bu sayının türü uint256 ve veri türü 32 bayt, ihtiyacınız var onaltılık değer 32 bayt ile doldurulur ve veri öğesinin sonucu 0x0000000000000000000000000000000000000000000000000000002b279b800000000000000000000000000000000 0000 00000000000000000000008a1858.
Adres
Adres alanı, olayı yayınlayan sözleşmenin adresidir, bu alanla ilgili önemli bir not, konu bölümünde yer almasa bile dizine eklenecektir. Bunun nedeni, Transfer olayının ERC20 standardının bir parçası olmasıdır, yani ERC20 transfer olaylarının günlüklerini filtrelemek gerektiğinde, transfer olayları tüm ERC20 sözleşmelerinden elde edilecektir. Ve sözleşme adresini endeksleyerek, arama, örnekteki USDT gibi belirli bir sözleşmeye/token'a kadar daraltılabilir.
İşlem Kodları İşlem Kodları
Son olarak LOG işlem kodu var. Hiçbir konu olmadığında LOG0'dan 4 konu olduğunda LOG4'e kadar değişir. LOG3, örneğimizde kullandığımız şeydir. Aşağıdakileri içerir:
(Kaynak:
ofset ve uzunluk, verilerin bellekteki veri bölümünde nerede bulunduğunu tanımlar.
Günlüğün yapısını ve bir konunun nasıl dizine eklendiğini anladıktan sonra, dizin öğelerinin nasıl arandığını anlayalım.
Bloom Filtreleri Bloom Filtreleri
Öğelerin daha hızlı aranmasını indekslemenin sırrı Bloom filtresidir.
Llimllib makalesi, bu veri yapısının iyi bir tanımına ve açıklamasına sahiptir.
"Bloom filtresi, bir öğenin bir koleksiyonda olup olmadığını belirlemek için kullanılabilen bir veri yapısıdır. Hızlı çalışma ve küçük bellek alanı özelliklerine sahiptir. Verimli ekleme ve sorgulamanın maliyeti, Bloom Filtresinin olasılık tabanlı bir veri olmasıdır. yapı: Bize yalnızca bir öğenin kesinlikle kümede olmadığını veya muhtemelen kümede olmadığını söyleyebilir.Bloom filtresinin altında yatan veri yapısı bir bit vektörüdür.
Aşağıda bir bit vektörü örneği verilmiştir. Beyaz hücreler, 0 değerine sahip bitleri ve yeşil hücreler, 1 değerine sahip bitleri temsil eder.
Bu bitler, bir miktar girdi alınarak ve hash edilerek 1'e ayarlanır, elde edilen hash değeri, bitin güncellenmesi gereken bir bit dizini olarak kullanılır. Yukarıdaki bit vektörü, 2 bitlik bir dizin elde etmek için "ethereum" değerine 2 farklı karma uygulamanın sonucudur. Karma, onaltılık bir sayıyı temsil eder ve dizini elde etmek için sayıyı alıp 0 ile 14 arasında bir değere dönüştürürsünüz. Mod 14 gibi bunu yapmanın birçok yolu vardır.
Gözden geçirmek
İşlemler için bir Bloom filtresiyle, yani bir bit vektörüyle, bit vektöründeki hangi bitlerin güncelleneceğini belirlemek için Ethereum'da karma yapılabilir.Giriş, adres alanı ve olay günlüğünün konusudur. İşleme özel bir Bloom filtresi olan işlem fişindeki logsBloom'u inceleyelim. Bir işlem, tüm günlüklerin adresini / konusunu içeren birden fazla günlük içerebilir.
Blok başlığına geri bakarsanız, başka bir logsBloom bulacaksınız. Bu, blok içindeki tüm işlemler için bir Bloom filtresidir. Her işlem için her günlükteki tüm adresleri/konuları içerir.
Bu Bloom filtreleri ikili değil onaltılık olarak ifade edilir. 256 bayt uzunluğundadırlar ve 2048 bitlik bir vektörü temsil ederler. Yukarıdaki Llimllib örneğine bakarsak, bit vektör uzunluğumuz 15'tir ve bit indeksleri 2 ve 13, 1 olarak çevrilir. Bakalım bunu hex'e çevirdiğimizde ne elde edeceğiz.
Onaltılık gösterim bir bit vektörü gibi görünmese de logsBloom'da öyledir.
Sorgu Sorguları
Daha önce "Kimden" adresi 0x5041ed759dd4afc3a72b8192c143f72f4724081a olan Transfer türünün X ve Y blokları arasındaki tüm olay günlüklerini bul" şeklinde bir sorgudan bahsedilmişti. Transfer türünde bir konuyu temsil eden event imza konusunu ve from (0x5041…) değerini alabilir ve Bloom filtresinde hangi bit indekslerinin 1 yapılması gerektiğini belirleyebiliriz.
Blok başlığında logsBloom kullanırsanız, bu bitlerden herhangi birinin 1'e ayarlanıp ayarlanmadığını kontrol edebilirsiniz. Değilse, blokta koşulla eşleşen günlük olmadığı belirlenebilir. Ve bu bitlerin ayarlanmış olduğu bulunursa, eşleşen bir günlüğün muhtemelen blokta olduğunu biliyoruz. Ancak tam olarak emin değilim çünkü logsBloom blok başlığı birden fazla adres ve konudan oluşuyor. Diğer olay günlüklerinde eşleştirme bitleri ayarlanmış olabilir. Bu nedenle bir Bloom filtresi olasılıksal bir veri yapısıdır. Bit vektörü ne kadar büyük olursa, diğer günlüklerle bit dizini çakışmalarının meydana gelme olasılığı o kadar az olur. Eşleşen bir Bloom filtreniz olduğunda, logsBloom'u tek tek makbuzlar için sorgulamak için aynı yöntemi kullanabilirsiniz. Bir eşleşme elde edildiğinde, nesneyi almak için gerçek günlük girişi görüntülenebilir.
Kriterleri karşılayan tüm günlükleri hızlı bir şekilde bulmak ve almak için X'ten Y'ye kadar olan bloklarda yukarıdaki işlemleri yürütün. Bloom filtresi kavramsal olarak bu şekilde çalışır.
Şimdi Ethereum'da kullanılan uygulamaya bakalım.
Geth uygulaması - Bloom Filtreleri
Artık Bloom filtresinin nasıl çalıştığını öğrendiğimize göre, Bloom filtresinin gerçek bir blokta adres / konudan logsBloom'a kadar adım adım taramayı nasıl tamamladığını öğrenelim.
Öncelikle Ethereum Yellow Paper'ın tanımından:
Kaynak:
"Günlük girişlerini tek bir 256 baytlık hash'e indirgeyen bir Bloom filtre işlevi M tanımlıyoruz:
içinde
keyfi bir bayt dizisi verildiğinde 2048'de üç bit ayarlayan özel bir Bloom filtresidir. Bu, bayt dizisinin Keccak-256 hash'indeki ilk üç bayt çiftinin her birinin alt 11 biti alınarak yapılır. "
Yukarıdaki tanımların anlaşılmasını basitleştirmek için aşağıda bir Geth istemci uygulamasına ilişkin bir örnek ve referans verilmiştir.
İşte Etherscan'de incelediğimiz işlem günlüğü.
İlk konu 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef olay imzasıdır ve bu değeri güncellenmesi gereken bit dizinine dönüştürür.
Geth kod tabanından bloomValues fonksiyonu aşağıdadır.
Bu işlev, 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef gibi olay imza konusunu ve diğer verileri alır ve Bloom filtresinde güncellenmesi gereken bit dizinini döndürür.
kod kaynağı:
Sarı Kağıt parçacığına bakın, "Bir bayt dizisinin Keccak-256 karmasındaki ilk üç çift bayt". Bu üç bayt çifti, hashbuf'un uzunluğu olan 6 bayttır.
Örnek veriler: 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef.
3 v1'i hesaplayın.
hashbuf [1] = 0xa3 = 10100011 bitsel VE 0x7 ile. 0x7 = 00000111.
Bir bayt 8 bitten oluşur.Bir bit indeksi almak istiyorsanız, elde edilen değerin sıfır indeks dizisinin 0 ile 7 arasında olduğundan emin olmanız gerekir. Hashbuf için bit düzeyinde AND kullanın [1] 0 ile 7 arasındaki değerlerle sınırlıdır. Örnekte hesaplanmıştır, 10100011 & 00000111 = 00000011 = 3.
Bu bit dizini değeri, bir ters çevrilmiş bit oluşturmak için bir bit kaydırma operatörüyle, yani 3 bit sola kaydırılarak 8 bitlik bayt dizini 00001000 ile sonuçlanır.
v1, gerçek bit dizini yerine tüm bayttır, çünkü bu değer daha sonra Bloom filtresinde bit düzeyinde VEYA'ya tabi tutulacaktır. VEYA işlemi, Bloom filtresindeki karşılık gelen tüm bitlerin de çevrilmesini sağlayacaktır.
Hashbuf'u, örnekte 0xada3 = 1010110110100011 olan bit dizisinin ilk 2 baytını sınırlamasını sağlayan big-endian uint16 bayt sırasına göre koyun.
Bitsel VE bu değer 0x7ff = 0000011111111111 ile. 0x7ff'nin 1'e ayarlandığı 11 bit vardır. Sarı kağıtta belirtildiği gibi, "bunu ilk üç çiftin her birinin alt 11 bitini alarak yapar". Bu, 1010110110100011 ve 0000011111111111 olan 0000010110100011 değeriyle sonuçlanacaktır.
Ardından değeri 3 bit sağa kaydırın. Bu, 11 basamaklı bir sayıyı 8 basamaklı bir sayıya dönüştürür. Bir bayt dizini istiyoruz ve Bloom filtresinin bayt uzunluğu 256, bu nedenle bayt dizin değerinin bu aralıkta olması gerekiyor. Ve 8 bitlik bir sayı, 0 ile 255 arasında herhangi bir değer olabilir. Örneğimizde bu değer 0000010110100011 3 bit sağa kaydırılmıştır 10110100 = 180.
256 eksi hesaplanan 180 eksi 1 olduğunu bilerek bayt dizinimizi BloomByteLength ile hesaplayın. Sonucu 0 ile 255 arasında tutmak için 1 çıkarın. Bu bize güncellenecek bayt dizinini verir, bu durumda bunun bayt 75 olduğu ortaya çıkar, i1'i bu şekilde hesapladık.
Yalnızca ilk bayt çifti olan 0xada3'ü ele aldık, bu işlem yine 2 ve 3 numaralı bayt çiftleri için yapıldı. Her adres / konu, 2048 bit vektörde 3 bit güncelleyecektir. Sarı Kitapta bahsedildiği gibi, "Bloom filtresi, rasgele bir bayt dizisi verildiğinde 2048'de üç bit ayarlar".
Bayt çifti 2 durum güncellemeleri, bit dizini 1'i bayt 195'te günceller (3 ve 4 numaralı prosedürlere göre yürütün, sonuç şekilde gösterilmiştir).
Bayt 123'te Bayt çifti 3 durum güncelleme bit dizini 4.
Güncellenecek bit başka bir konu tarafından çevrilmişse, olduğu gibi kalacaktır. Olmazsa 1'e döner.
Yukarıdaki işlem sürecinde, olay imza konusunun Bloom filtresinde aşağıdaki bitleri çevireceği belirlenebilir:
İkiliye dönüştürülen işlem makbuzunda logBlooms'a bakıldığında, bu bit indekslerinin ayarlandığı doğrulanır.
Bu arada, günlük arama ve Bloom filtresinin uygulanması hakkında daha fazla bilgi edinmek isteyen okuyucular için BloomBits Trie makalesine başvurabilirsiniz.
Bu noktada, EVM serisi makalelerle ilgili derinlemesine tartışmamız sona erdi ve gelecekte daha yüksek kaliteli teknik makaleleri sizlerle buluşturacağız.