Akıllı sözleşmeler alanında "Ethereum Virtual Machine EVM" ve algoritmaları ve veri yapıları ilk prensiplerdir.
Bu makale, sözleşmelerin neden sınıflandırılması gerektiğinden başlar ve her senaryonun ne tür kötü niyetli saldırılarla karşı karşıya kalabileceğini birleştirir ve son olarak nispeten güvenli bir dizi sözleşme sınıflandırma analizi algoritması verir.
**Teknik içeriği yüksek olsa da, çeşitli konuşmalar için bir okuma materyali olarak da kullanılabilir **Merkezi olmayan sistemler arasındaki karanlık oyun ormanına bir göz atın.
1. Sözleşmeler neden sınıflandırılmalı?
Çok önemli olduğu için borsalar, cüzdanlar, blockchain tarayıcıları, veri analiz platformları vb. gibi Dapp'lerin temel taşı olduğu söylenebilir!
Bir işlemin ERC20 transferi olmasının nedeni, davranışının ERC20 standardına uygun olmasıdır, en azından:
İşlemin durumu başarılı
Kime adresi, ERC20 standardına uygun bir sözleşmedir
Transfer işlevi çağrılır ve özelliği, işlemin CallData'sının ilk 4 hanesinin 0xa9059cbb olmasıdır.
Yürütmeden sonra, Kime adresine bir aktarım olayı gönderilir.
Sınıflandırma yanlışsa, işlem davranışı yanlış değerlendirilecektir
İşlem davranışının mihenk taşı olmasıyla, Kime adresinin doğru bir şekilde sınıflandırılıp sınıflandırılamayacağı, CallData'nın değerlendirilmesinde tamamen farklı bir sonuca yol açacaktır. Dapp için zincir içi ve zincir dışı bilgi iletişimi, büyük ölçüde işlem olaylarının izlenmesine bağlıdır ve aynı olay koduna ancak standartları karşılayan bir sözleşmeyle gönderildiğinde güvenilebilir.
Sınıflandırma yanlışsa işlem yanlışlıkla kara deliğe girecek
Kullanıcı bir Token'ı belirli bir sözleşmeye aktarırsa, sözleşmede Token transferi için önceden ayarlanmış bir işlev yöntemi yoksa, fonlar Burn ile aynı şekilde kilitlenir ve kontrol edilemez.
Ve artık çok sayıda proje yerleşik cüzdan desteği eklemeye başladığından, kullanıcılar için cüzdanları yönetmek kaçınılmazdır.Zincirden en son dağıtılan sözleşmeleri her zaman gerçek zamanlı olarak sınıflandırmak gerekir. varlık standartları.
2. Sınıflandırmanın riskleri nelerdir?
**Zincir, kimliğin ve hukukun üstünlüğünün olmadığı bir yerdir.Normal bir işlemi, kötü niyetli de olsa durduramazsınız. **
Büyükanne gibi davranan, bir büyükanneden yapmasını beklediğiniz davranışların çoğunu yapan, ancak amacı eve girip soymak olan bir kurt olabilir.
Talepler standarttır, ancak gerçekte karşılamayabilir
Yaygın bir sınıflandırma yöntemi, adresin ERC20 vb. destekleyip desteklemediğini okumak için doğrudan EIP-165 standardını benimsemektir. sonuçta sahte.
165 standart sorgusu, zincirdeki sınırlı işlem kodları arasında en düşük maliyetle fonların kara deliklere aktarılmasını engelleyen bir yöntemdir.
Bu nedenle, daha önce NFT'yi analiz ettiğimizde, standartta bir SafeTransferFrom yöntemi olacağından özellikle bahsetmiştik, burada Safe, karşı tarafın NFT'yi aktarma yeteneğine sahip olduğunu belirlemek için 165 standardının kullanılmasını ifade eder.
Yalnızca sözleşme bayt kodundan başlayarak, kaynak kod düzeyinde statik analiz yaparak ve sözleşmenin beklenen davranışından başlayarak daha doğru olabilir.
3. Sözleşme sınıflandırma şeması tasarımı
Ardından, genel planı sistematik olarak analiz edeceğiz ve nihai hedefimizin "kesinlik" ve "verimlilik" olmak üzere iki temel gösterge olduğunu not edeceğiz. **
Bilmelisiniz ki yön doğru olsa bile okyanusun diğer tarafına ulaşmanın yolu belli değildir.Bytecode analizi yapmak için ilk durak kodu elde etmektir.
3.1.Kod nasıl alınır?
Zincire gitme açısından, zincirde belirtilen adresten bytecode alabilen bir RPC yöntemi olan getCode vardır.Hesap yapısına codeHash yerleştirildiği için okuma açısından çok hızlıdır. EVM'nin en üstünde.
Ancak bu yöntem, tek başına belirli bir adresi elde etmekle eşdeğerdir.Doğruluğu ve verimliliği daha da artırmak ister misiniz?
Bu bir sözleşme konuşlandırma işlemiyse, konuşlandırılan kod yürütüldükten hemen sonra veya hatta hala bellek havuzundayken nasıl alınır?
İşlem sözleşmeli fabrika modundaysa, işlemin Calldata'sında herhangi bir kaynak kodu var mı?
Sonunda, benim yolum elek benzeri bir modda sınıflandırmak.
Sözleşmesiz dağıtılan işlemler için, sınıflandırma için ilgili adresleri elde etmek üzere getCode'u doğrudan kullanın.
En son bellek havuzu işlemleri için, adresi boş olan ve yapıcı ile kaynak kodu CallData olan işlemleri filtreleyin
Sözleşmeli fabrika modunun işlemi için, sözleşme tarafından konuşlandırılan sözleşme, dağıtımı yürütmek için diğer sözleşmeleri geri dönüştürebileceğinden ve çağırabileceğinden, işlemin alt işlemlerini yinelemeli olarak analiz edecek ve türü CREATE veya CREATE olan her çağrıyı kaydedecektir. OLUŞTUR2 .
Bir demo uygulaması yaptığımda, rpc sürümünün şu anda nispeten yüksek olduğunu gördüm, çünkü tüm sürecin en zor kısmı, 3 yürütülürken belirtilen türdeki çağrının tekrar tekrar nasıl bulunacağıdır. Alt düzey yöntem, geri yüklemektir. opcode aracılığıyla bağlam.Ben şaşırdım!
Neyse ki, geçerli geth sürümünde, işlem kodu işlem kodu aracılığıyla her çağrının bağlam bilgisini düzenlemeye ve çekirdek alanları düzenlemeye yardımcı olabilecek bir debug_traceTransaction yöntemi vardır.
Sonunda, çeşitli dağıtım modlarının orijinal bayt kodları (doğrudan dağıtım, fabrika modunda tek dağıtım, fabrika modunda toplu dağıtım) elde edilebilir.
3.2 Koddan nasıl sınıflandırma yapılır?
En basit ama güvenli olmayan yol direkt olarak kod ile dizi eşleştirme yapmaktır.ERC20 örnek alınırsa standarda uyan fonksiyon
Fonksiyon adından sonra fonksiyonun fonksiyon imzası gelir.Önceki analizde bahsedildiği gibi işlem, hedef fonksiyonu bulmak için callData'nın ilk 4 hanesini eşleştirmeye bağlıdır.Daha fazla bilgi için:
Bu nedenle, bu 6 işlevin imzaları sözleşme bayt kodunda saklanmalıdır.
Tabii ki, bu yöntem çok hızlı ve 6'sını da bulabilirsiniz, ancak güvenli olmayan faktör şu ki, sağlamlık sözleşmesini kullanırsam ve depolama değeri 0x18160ddd olan bir değişken tasarlarsam, o zaman bu işleve sahip olduğumu düşünecek.
3.3. Doğruluk oranı iyileştirmesi 1- kaynak koda dönüştürme
Daha doğru yöntem, Opcode'u kaynak koda dönüştürmektir! Kaynak koda dönüştürme, elde edilen bayt kodlarını işlem kodlarına dönüştürme işlemidir ve daha gelişmiş kaynak koda dönüştürme, bunları insan okuması için daha elverişli olan sözde kodlara dönüştürmektir. Bu sefer buna ihtiyacımız yok. Kaynak koda dönüştürme yöntemi, adresindeki ekte listelenmiştir. makalenin sonu.
sağlamlık (yüksek seviyeli dil) -> bayt kodu (bayt kodu) -> işlem kodu (işlem kodu)
Açıkça bir özellik bulabiliriz, işlev imzası PUSH4 işlem kodu tarafından yürütülecektir, bu nedenle sonraki yöntem, PUSH4'ten sonraki içeriği tam metinden çıkarmak ve işlev standardıyla eşleştirmektir.
Ayrıca basit bir performans deneyi yaptım ve şunu söylemeliyim ki Go dili çok verimli ve 10.000 kez kaynak koda dönüştürme işlemi yalnızca 220 ms sürüyor.
Sonrası zor olacak
3.4. Doğruluk oranı iyileştirme 2-bulma kod bloğu
Yukarıdaki doğruluk oranı iyileştirildi ancak yeterli değil, çünkü tam metin araması PUSH4, çünkü yine de PUSH4 komutunu tetikleyecek byte4 türünde bir değişken oluşturabiliyoruz.
Sıkıntıya düştüğümde aklıma bazı açık kaynak projelerin uygulanması geldi.ETL, analiz için zincirdeki verileri okumak için bir araçtır.ERC20 ve 721'in transferini ayrı tablolara analiz edecek, bu yüzden sınıflandırma yeteneğine sahip olmalı. sözleşmeler.
Analizden sonra, kod bloklarının sınıflandırılmasına dayandığı ve yalnızca ilk temel_blokları işlediği bulunabilir. [0] push4 komutu
Soru gelir, kod bloğunun nasıl doğru bir şekilde değerlendirileceği
Kod bloğu kavramı REVERT + JUMPDEST ardışık iki opcode'dan gelir.Burada iki ardışık opcode olmalıdır çünkü tüm fonksiyon seçicinin opcode aralığında çok fazla fonksiyon varsa sayfa çevirme mantığı çıkacaktır. .Ardından JUMPDEST komutu da görünecektir.
3.5. Doğruluk oranı iyileştirme 3-Bul işlevi seçici
İşlev seçicinin işlevi, işlemin Calldata'sının ilk 4 baytını okumak ve bunu kodda önceden ayarlanmış sözleşme işlevi imzasıyla eşleştirmek ve işlev yöntemi tarafından belirtilen bellek konumuna atlama talimatına yardımcı olmaktır.
Minimal bir sahte yürütme deneyelim
Bu kısım iki fonksiyonun selector store(uint 256) ve retrieve() kısmıdır ve imza 2e64cec1, 6057361d olarak hesaplanabilir.
Derlemeden sonra, iki bölüme ayrıldığı söylenebilecek aşağıdaki opcode dizesini alacaksınız.
ilk kısım:
Derleyicide, sözleşmenin yalnızca işlev seçici kısmı, aşağıdaki şekilde gösterildiği gibi, CallData'nın işlev çağrısı imzasını almak anlamına gelen callData içeriğini alacaktır.
EVM'nin bellek havuzundaki değişimi simüle ederek etkiyi görebiliriz.
ikinci kısım:
Seçicinin değeriyle eşleşip eşleşmediğini yargılama süreci
EQ işlem kodu, yığın alanından 2 değişken, yani 0x2e64cec1 ve 0x6057361d çıkarır ve eşit olup olmadıklarını kontrol eder
PUSH2, yığına 2 bayt veri aktarır (burada 0x003b, ondalık olarak 59) Yığın alanında, bayt kodundaki bir sonraki yürütme komutunun konumunu belirten bir program sayacı vardır. Burada 59'u ayarladık çünkü geri alma() bayt kodu burada başlar
JUMPI "Eğer..." anlamına gelir, yığından girdi olarak 2 değer çıkarır ve koşul doğruysa program sayacı 59'a güncellenir.
EVM, sözleşmedeki işlev çağrısına göre yürütmesi gereken işlev bayt kodunun konumunu bu şekilde belirler.
Gerçekte bu, sözleşmedeki her işlev ve nereye atladıkları için basit bir "if ifadeleri" kümesidir.
4. Şema Özeti
Genel özet şu şekilde
Her sözleşme adresi, dağıtımdan sonra bayt kodunu, GO'daki VM ve ASM kitaplıklarını kullanarak rpcgetcode veya debug_traceTransaction aracılığıyla alabilir ve işlem kodu, derlemeden sonra elde edilebilir
EVM çalışma prensibinde, sözleşme aşağıdaki özelliklere sahip olacaktır:
Kod bloğu ayrımı olarak REVERT+JUMPDEST kullanın
Sözleşme, bir işlev seçici işlevine sahip olmalı ve bu işlev de ilk kod bloğunda olmalıdır.
İşlev seçicide, işlev yöntemlerinin tümü işlem kodu olarak PUSH4'ü kullanır,
Bu seçicide yer alan işlem kodunda art arda PUSH1 00; CALLDATALOAD; PUSH1 e0; SHR; DUP1 olacaktır. Temel işlev, callDate verilerini yüklemek ve yer değiştirme işlemlerini gerçekleştirmektir. Sözleşme işlevinden, diğer söz dizimi oluşturulmaz
İlgili işlev imzası eip'te tanımlanmıştır ve zorunlu ve isteğe bağlı açık talimatlar vardır.
4.1. Benzersizlik Kanıtı
Bu noktada verimliliği yüksek ve doğruluğu yüksek bir sözleşme analiz yönteminin temel olarak gerçekleştirildiğini söyleyebiliriz.Tabii ki bu kadar uzun süredir titiz olduğu için daha titiz davranabiliriz.Yukarıdaki şemada kod bloğu REVER+JUMPDEST Distinguish'e dayalıdır ve benzersiz bir karar vermek için kaçınılmaz CallDate yükleme ve yer değiştirmeyi birleştirir.Benzer bir işlem kodu dizisini uygulamak için bir katılık sözleşmesi kullanabilir miyim?
Bir kontrol deneyi yaptım.Solidity dilbilgisi düzeyinden msg.sig gibi CallData elde etmenin yöntemleri olsa da, derlemeden sonra opcode'un uygulama yöntemleri farklıdır.
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.
Derinlemesine EVM-sözleşme sınıflandırmasının önemsiz meselesinin ardındaki riskler
Akıllı sözleşmeler alanında "Ethereum Virtual Machine EVM" ve algoritmaları ve veri yapıları ilk prensiplerdir.
Bu makale, sözleşmelerin neden sınıflandırılması gerektiğinden başlar ve her senaryonun ne tür kötü niyetli saldırılarla karşı karşıya kalabileceğini birleştirir ve son olarak nispeten güvenli bir dizi sözleşme sınıflandırma analizi algoritması verir.
**Teknik içeriği yüksek olsa da, çeşitli konuşmalar için bir okuma materyali olarak da kullanılabilir **Merkezi olmayan sistemler arasındaki karanlık oyun ormanına bir göz atın.
1. Sözleşmeler neden sınıflandırılmalı?
Çok önemli olduğu için borsalar, cüzdanlar, blockchain tarayıcıları, veri analiz platformları vb. gibi Dapp'lerin temel taşı olduğu söylenebilir!
Bir işlemin ERC20 transferi olmasının nedeni, davranışının ERC20 standardına uygun olmasıdır, en azından:
Sınıflandırma yanlışsa, işlem davranışı yanlış değerlendirilecektir
İşlem davranışının mihenk taşı olmasıyla, Kime adresinin doğru bir şekilde sınıflandırılıp sınıflandırılamayacağı, CallData'nın değerlendirilmesinde tamamen farklı bir sonuca yol açacaktır. Dapp için zincir içi ve zincir dışı bilgi iletişimi, büyük ölçüde işlem olaylarının izlenmesine bağlıdır ve aynı olay koduna ancak standartları karşılayan bir sözleşmeyle gönderildiğinde güvenilebilir.
Sınıflandırma yanlışsa işlem yanlışlıkla kara deliğe girecek
Kullanıcı bir Token'ı belirli bir sözleşmeye aktarırsa, sözleşmede Token transferi için önceden ayarlanmış bir işlev yöntemi yoksa, fonlar Burn ile aynı şekilde kilitlenir ve kontrol edilemez.
Ve artık çok sayıda proje yerleşik cüzdan desteği eklemeye başladığından, kullanıcılar için cüzdanları yönetmek kaçınılmazdır.Zincirden en son dağıtılan sözleşmeleri her zaman gerçek zamanlı olarak sınıflandırmak gerekir. varlık standartları.
2. Sınıflandırmanın riskleri nelerdir?
**Zincir, kimliğin ve hukukun üstünlüğünün olmadığı bir yerdir.Normal bir işlemi, kötü niyetli de olsa durduramazsınız. **
Büyükanne gibi davranan, bir büyükanneden yapmasını beklediğiniz davranışların çoğunu yapan, ancak amacı eve girip soymak olan bir kurt olabilir.
Talepler standarttır, ancak gerçekte karşılamayabilir
Yaygın bir sınıflandırma yöntemi, adresin ERC20 vb. destekleyip desteklemediğini okumak için doğrudan EIP-165 standardını benimsemektir. sonuçta sahte.
165 standart sorgusu, zincirdeki sınırlı işlem kodları arasında en düşük maliyetle fonların kara deliklere aktarılmasını engelleyen bir yöntemdir.
Bu nedenle, daha önce NFT'yi analiz ettiğimizde, standartta bir SafeTransferFrom yöntemi olacağından özellikle bahsetmiştik, burada Safe, karşı tarafın NFT'yi aktarma yeteneğine sahip olduğunu belirlemek için 165 standardının kullanılmasını ifade eder.
Yalnızca sözleşme bayt kodundan başlayarak, kaynak kod düzeyinde statik analiz yaparak ve sözleşmenin beklenen davranışından başlayarak daha doğru olabilir.
3. Sözleşme sınıflandırma şeması tasarımı
Ardından, genel planı sistematik olarak analiz edeceğiz ve nihai hedefimizin "kesinlik" ve "verimlilik" olmak üzere iki temel gösterge olduğunu not edeceğiz. **
Bilmelisiniz ki yön doğru olsa bile okyanusun diğer tarafına ulaşmanın yolu belli değildir.Bytecode analizi yapmak için ilk durak kodu elde etmektir.
3.1.Kod nasıl alınır?
Zincire gitme açısından, zincirde belirtilen adresten bytecode alabilen bir RPC yöntemi olan getCode vardır.Hesap yapısına codeHash yerleştirildiği için okuma açısından çok hızlıdır. EVM'nin en üstünde.
Ancak bu yöntem, tek başına belirli bir adresi elde etmekle eşdeğerdir.Doğruluğu ve verimliliği daha da artırmak ister misiniz?
Bu bir sözleşme konuşlandırma işlemiyse, konuşlandırılan kod yürütüldükten hemen sonra veya hatta hala bellek havuzundayken nasıl alınır?
İşlem sözleşmeli fabrika modundaysa, işlemin Calldata'sında herhangi bir kaynak kodu var mı?
Sonunda, benim yolum elek benzeri bir modda sınıflandırmak.
Bir demo uygulaması yaptığımda, rpc sürümünün şu anda nispeten yüksek olduğunu gördüm, çünkü tüm sürecin en zor kısmı, 3 yürütülürken belirtilen türdeki çağrının tekrar tekrar nasıl bulunacağıdır. Alt düzey yöntem, geri yüklemektir. opcode aracılığıyla bağlam.Ben şaşırdım!
Neyse ki, geçerli geth sürümünde, işlem kodu işlem kodu aracılığıyla her çağrının bağlam bilgisini düzenlemeye ve çekirdek alanları düzenlemeye yardımcı olabilecek bir debug_traceTransaction yöntemi vardır.
Sonunda, çeşitli dağıtım modlarının orijinal bayt kodları (doğrudan dağıtım, fabrika modunda tek dağıtım, fabrika modunda toplu dağıtım) elde edilebilir.
3.2 Koddan nasıl sınıflandırma yapılır?
En basit ama güvenli olmayan yol direkt olarak kod ile dizi eşleştirme yapmaktır.ERC20 örnek alınırsa standarda uyan fonksiyon
Fonksiyon adından sonra fonksiyonun fonksiyon imzası gelir.Önceki analizde bahsedildiği gibi işlem, hedef fonksiyonu bulmak için callData'nın ilk 4 hanesini eşleştirmeye bağlıdır.Daha fazla bilgi için:
Bu nedenle, bu 6 işlevin imzaları sözleşme bayt kodunda saklanmalıdır.
Tabii ki, bu yöntem çok hızlı ve 6'sını da bulabilirsiniz, ancak güvenli olmayan faktör şu ki, sağlamlık sözleşmesini kullanırsam ve depolama değeri 0x18160ddd olan bir değişken tasarlarsam, o zaman bu işleve sahip olduğumu düşünecek.
3.3. Doğruluk oranı iyileştirmesi 1- kaynak koda dönüştürme
Daha doğru yöntem, Opcode'u kaynak koda dönüştürmektir! Kaynak koda dönüştürme, elde edilen bayt kodlarını işlem kodlarına dönüştürme işlemidir ve daha gelişmiş kaynak koda dönüştürme, bunları insan okuması için daha elverişli olan sözde kodlara dönüştürmektir. Bu sefer buna ihtiyacımız yok. Kaynak koda dönüştürme yöntemi, adresindeki ekte listelenmiştir. makalenin sonu.
sağlamlık (yüksek seviyeli dil) -> bayt kodu (bayt kodu) -> işlem kodu (işlem kodu)
Açıkça bir özellik bulabiliriz, işlev imzası PUSH4 işlem kodu tarafından yürütülecektir, bu nedenle sonraki yöntem, PUSH4'ten sonraki içeriği tam metinden çıkarmak ve işlev standardıyla eşleştirmektir.
Ayrıca basit bir performans deneyi yaptım ve şunu söylemeliyim ki Go dili çok verimli ve 10.000 kez kaynak koda dönüştürme işlemi yalnızca 220 ms sürüyor.
Sonrası zor olacak
3.4. Doğruluk oranı iyileştirme 2-bulma kod bloğu
Yukarıdaki doğruluk oranı iyileştirildi ancak yeterli değil, çünkü tam metin araması PUSH4, çünkü yine de PUSH4 komutunu tetikleyecek byte4 türünde bir değişken oluşturabiliyoruz.
Sıkıntıya düştüğümde aklıma bazı açık kaynak projelerin uygulanması geldi.ETL, analiz için zincirdeki verileri okumak için bir araçtır.ERC20 ve 721'in transferini ayrı tablolara analiz edecek, bu yüzden sınıflandırma yeteneğine sahip olmalı. sözleşmeler.
Analizden sonra, kod bloklarının sınıflandırılmasına dayandığı ve yalnızca ilk temel_blokları işlediği bulunabilir. [0] push4 komutu
Soru gelir, kod bloğunun nasıl doğru bir şekilde değerlendirileceği
Kod bloğu kavramı REVERT + JUMPDEST ardışık iki opcode'dan gelir.Burada iki ardışık opcode olmalıdır çünkü tüm fonksiyon seçicinin opcode aralığında çok fazla fonksiyon varsa sayfa çevirme mantığı çıkacaktır. .Ardından JUMPDEST komutu da görünecektir.
3.5. Doğruluk oranı iyileştirme 3-Bul işlevi seçici
İşlev seçicinin işlevi, işlemin Calldata'sının ilk 4 baytını okumak ve bunu kodda önceden ayarlanmış sözleşme işlevi imzasıyla eşleştirmek ve işlev yöntemi tarafından belirtilen bellek konumuna atlama talimatına yardımcı olmaktır.
Minimal bir sahte yürütme deneyelim
Bu kısım iki fonksiyonun selector store(uint 256) ve retrieve() kısmıdır ve imza 2e64cec1, 6057361d olarak hesaplanabilir.
Derlemeden sonra, iki bölüme ayrıldığı söylenebilecek aşağıdaki opcode dizesini alacaksınız.
ilk kısım:
Derleyicide, sözleşmenin yalnızca işlev seçici kısmı, aşağıdaki şekilde gösterildiği gibi, CallData'nın işlev çağrısı imzasını almak anlamına gelen callData içeriğini alacaktır.
EVM'nin bellek havuzundaki değişimi simüle ederek etkiyi görebiliriz.
ikinci kısım:
Seçicinin değeriyle eşleşip eşleşmediğini yargılama süreci
4 baytlık işlev imzasını (0x2e64cec1) yığıta geçirin (0x2e64cec1),
EQ işlem kodu, yığın alanından 2 değişken, yani 0x2e64cec1 ve 0x6057361d çıkarır ve eşit olup olmadıklarını kontrol eder
PUSH2, yığına 2 bayt veri aktarır (burada 0x003b, ondalık olarak 59) Yığın alanında, bayt kodundaki bir sonraki yürütme komutunun konumunu belirten bir program sayacı vardır. Burada 59'u ayarladık çünkü geri alma() bayt kodu burada başlar
JUMPI "Eğer..." anlamına gelir, yığından girdi olarak 2 değer çıkarır ve koşul doğruysa program sayacı 59'a güncellenir.
EVM, sözleşmedeki işlev çağrısına göre yürütmesi gereken işlev bayt kodunun konumunu bu şekilde belirler.
Gerçekte bu, sözleşmedeki her işlev ve nereye atladıkları için basit bir "if ifadeleri" kümesidir.
4. Şema Özeti
Genel özet şu şekilde
4.1. Benzersizlik Kanıtı
Bu noktada verimliliği yüksek ve doğruluğu yüksek bir sözleşme analiz yönteminin temel olarak gerçekleştirildiğini söyleyebiliriz.Tabii ki bu kadar uzun süredir titiz olduğu için daha titiz davranabiliriz.Yukarıdaki şemada kod bloğu REVER+JUMPDEST Distinguish'e dayalıdır ve benzersiz bir karar vermek için kaçınılmaz CallDate yükleme ve yer değiştirmeyi birleştirir.Benzer bir işlem kodu dizisini uygulamak için bir katılık sözleşmesi kullanabilir miyim?
Bir kontrol deneyi yaptım.Solidity dilbilgisi düzeyinden msg.sig gibi CallData elde etmenin yöntemleri olsa da, derlemeden sonra opcode'un uygulama yöntemleri farklıdır.