Solidity Inline-Assembly for Developer Experience

Intro Baiklah, saya sudah berumur berkali-kali. Dalam masa percuma saya menjaga library ini yang dipanggil Solady iaitu library yang berbeza keterangan yang dikirakan kebanyakan dalam pembinaan dalam. Jadi hari ini saya akan bercakap tentang bagaimana kita menggunakan assembly dalam dalam untuk membuat perkara lebih mudah untuk pengguna library. Baiklah, jadi untuk mulakan, beberapa masa lalu saya menulis tweet ini mengatakan pemula menggunakan assembly untuk menyelamatkan gas kerana itu adalah perkara yang paling jelas. Pemula menggunakan assembly untuk mengelakkan limit Dragon Spirit.

Kerana assembly membuat kode byte anda lebih kecil. Seperti bahawa walaupun tanpa EOF, jika anda menggunakan Solady, anda mungkin dapat melihat seperti 20-30% kekurangan kode byte. Kemudian assembly pengguna lanc untuk menghidupkan masa. Setelah anda terbuka untuk menulis pembukaan dalam dalam, anda hanya menulis kod U Optima secara langsung. Jadi pembukaan dalam dalam dan U, kita boleh gunakannya secara bergantung dalam konteks ini.

Okey, jadi hari ini saya akan menerangkan sedikit kedua dan tiga, kedua dan ketiga. Baiklah, jadi beberapa contoh untuk dimulakan. Yang pertama adalah leap penyelesaian aman. Saya juga akan bercakap mengenai leap yang telah dilakukan di Solady. Jadi di Solady, kita mempunyai library ini untuk proksis.

Dan proksis kami adalah kebanyakan, saya akan mengatakan kebanyakan jika tidak semua proksis kami seperti yang telah ditulis secara langsung dalam kode kata. Kemudian kami juga menerangkan beberapa keadaan yang lebih tinggi seperti contohnya, lip salt dan bagaimana menggunakan assembly inline-z dapat membantu dalam ujian. Okey, jadi contohnya, kita gunakan ini, katakan jika anda ingin menghantar ether kepada seseorang dalam kontrak aksi tetapi bagaimana jika pembawa adalah kontrak yang mengusir atau tidak memanfaatkan fungsi terima. Jadi di Solady, kita mempunyai fungsi ini yang dipanggil force save transfer if yang menggunakan self-destruct untuk menghantar ether kepada orang. Jadi sebagai pengguna, anda tidak perlu peduli tentang semua ini.

Anda hanya menggunakan fungsi dan anda boleh sangat selamat bahawa ether akan dihantar kepada orang. Dan mengapa ini berguna? Kami tahu bahawa wrap if tidak berada di adres yang sama pada setiap L2. Jadi jika anda ingin mengembalikan kontrak anda ke adres Create2 yang sama dan anda menggunakan RepIf, ia agak mengalami masalah. Jadi, sebaliknya anda boleh menggunakan fungsi ini dan anda boleh menyelamatkan ruang dan masa otak anda.

ruang otak dan masa. Di DeepClone, kita mempunyai fungsi ini yang dipanggil deployERC1967 yang memanfaatkan proksi brightcode yang minimal yang boleh diubah. Jadi ia berdasarkan ERC 7760 ini. Proksi ini telah ditulis selama lebih dari sebulan. Tetapi baru-baru ini kami ingin menyatukan semua ini menjadi ERC supaya penjelajah berbuka dapat mengimplementasikan auto-verifikasi dengan mudah.

Oleh kerana ERC ini telah berada di sekitar, seperti proksi ini telah berada di sekitar selama semasa, ia juga telah mendapat sedikit penggunaan. Jadi dalam jenis basa, ia adalah proksi pilihan yang digunakan untuk wallet Smart Coinbase dan untuk Polygon, saya rasa mereka menggunakannya untuk sesuatu yang lain juga. Jadi ada lebih dari 100,000 contoh proksi ini yang digunakan di sekitar. Dan kelebihannya adalah bahawa ia cepat, ia kecil dan dalam beberapa kes ia auto-verifikasi. Jadi ia menjaga masa anda.

Anda tidak perlu melakukan beberapa alat API atau kebutuhan. Ia hanya memeriksa sendiri. Jadi DeepSort juga mempunyai beberapa fungsi yang berlaku tinggi yang boleh digunakan untuk tujuan ujian. Seperti kita ada operasi set pada array yang disort. Anda boleh gunakannya untuk ujian invariant.

Dan untuk ujian plus, kita tahu jika anda menulis ujian di Foundry, anda perlu menentukan variable random dalam argumen fungsi dan ada jumlah ruang yang terbatas yang boleh anda lakukan. Dan anda perlu memikirkan variable yang menarik yang saya rasa sangat mengambil masa. Jadi, saya menggunakan banyak magik hitam untuk menulis metode yang memungkinkan anda untuk menggunakan untuk menghasilkan serta-merta nombor yang serta di mana-mana di dalam kode anda. Jadi anda boleh melakukan sesuatu seperti pengujian cepat yang diperlukan. Dan jika anda ingin tahu bagaimana untuk mengintegrasikannya ke dalam projek anda, anda boleh mengikuti link di bawah.

Okey, jadi ini adalah beberapa kajian pelajaran yang anda mungkin ingin periksa. Satu perkara yang saya rasa agak menarik adalah dynamic array leak. Contohnya dalam SOID, jika anda menentukan array, anda tahu anda tidak boleh melakukan pen atau pushback tetapi di mana dynamic array leak ini mempunyai fungsi itu. Okey, jadi mengapa assembly dalam dalam adalah baik untuk penulis bibli seperti saya. Pertama, ia memberikan beberapa teknik seperti ia membantu saya melakukan beberapa penyelesaian kode supaya pengguna bibli tidak perlu risau bahawa bibli saya menyebabkan mereka mempunyai stack terlalu dalam.

Anda juga boleh mencari kumaf yang tidak terkendalikan dalam soliditi normal. Dan jika anda tahu bagaimana untuk memperkuat kompiler dengan arah yang benar, anda dapat mencapai beberapa ekstrak masa kompil tanda tanpa kos. Jadi, contohnya, mengelakkan stack terlalu dalam. Kami mempunyai fungsi ini yang dipanggil lon-what dalam fixed point math lib. Jika anda menggunakannya sendiri, kadang-kadang kompauler cuba untuk menggabungkannya dan ia menyebabkan stack terlalu dalam.

Tetapi jika anda menulis fungsi ini dalam assembly yang bergabung, anda boleh menggabungkan penggunaan yang diberikan, anda membantu kompon menggabung dengan cara yang mengelakkan stack terlalu dalam atau tanpa IR. Jadi dalam SOAD, kita sangat khas yang ia mesti berfungsi dalam sebanyak situasi yang mungkin. Jadi sama ada anda menggunakan via IR atau sama ada anda memilih untuk tidak menggunakan via IR, kita ingin memastikan ia berfungsi. Anda tidak perlu risau bahawa library kita adalah kalibran stack2d. Itulah sebabnya kita sangat khas dengan semua detail kecil ini.

Okey, kemudian, inline-SMB juga membolehkan kita membuat Math yang keren. Anda tidak perlu memahami apa itu, tetapi ada dengan Math, tetapi ada beberapa kode-kode op seperti kode byte dan kode op yang tidak berkaitan dengan branch, yang membolehkan kita membuat Math lebih cepat. Contohnya dalam metode log2 ini. Dan keuntungan mempunyai fungsi yang tidak berkaitan dengan branch yang boleh dilakukan dengan assembly dalam dalam adalah ketika kompauler soliditi cuba untuk mengoptimisir, ia akan mula memeriksa apakah fungsi anda mempunyai beberapa pangkalan. Jika ia mempunyai pangkalan, maka fungsi itu mungkin tidak boleh dilakukan dalam dalam dengan pipeline VRIR dan jika anda menggunakan pipeline legacy, ia pasti tidak akan berada dalam dalam.

Oleh itu, dengan menulis barang dalam InlineSMB, kami membantu kompiler menghasilkan kode yang lebih efisien dengan memberitahu kompiler bahawa fungsi ini boleh diterapkan dalam garis. Oleh itu, menggunakan trik ini, kami juga dapat mencapai teknik lain seperti jika anda ingin membandingkan string pendek dengan string pendek lain, sec, tradisional anda akan menggunakan jenis kata-kata Kikak 256 tetapi jika anda tahu assembly inline, anda boleh melakukan sebuah jenis magik hitam yang akan memberitahu kompiler bahawa daripada melakukan alokasi memori yang tidak berguna, hanya menggunakan opcode Optima. Jadi semua ini, walaupun ia kelihatan seperti banyak kode op, tetapi pada akhirnya setelah anda menekan Compile, ia secara sesuai menyelenggarakan menjadi hanya beberapa kode op. Dan ini hanya mungkin jika seluruh cat kode itu tidak berkumpulan. Baiklah, jadi perkara tentang Solidity adalah bahawa ia adalah bahasa yang sangat indah.

Anda boleh menulis semua perkara yang rendah dan pengguna tidak perlu bimbangkan detail. Jadi semua ketakutan, kegiatan, kegiatan hitam telah dikeluarkan dari pengguna. Pengguna perlu hanya peduli tentang apa adalah API tinggi dan apa adalah penggunaan semua fungsi yang berbeza. Jadi anda boleh menulis dengan bersih dan berkesan, pen soliti yang berada di tingkat tinggi yang dapat dibaca tanpa bergerak dalam lubang rabit yang tidak ada di dalam. Ada beberapa tujuan yang diperlukan seperti North Star of Solidity.

Kami ingin memastikan soliti adalah bahasa kontrak yang terbaik dengan mengeluarkan setelah menggunakan utiliti yang sangat optimis yang menjadikan Compiler Solidity sekarang dan ke depan. Jadi idea adalah orang-orang berkata kita ingin menulis bahasa kita dalam Rust kerana ia mempunyai library yang lebih luas. Kita ingin menulis dalam C++ because there's a wider library. But in SoilDT, we have this exotic math function called LambertW01 which is only available in Python, maybe some math language in SoilDT. You can find it in any other major languages.

So that is so ladies go. If it's Turing complete, if it's possible within the Turing complet kita akan memperbaikinya. Kami juga ingin mengukur Ethereum melalui pemotongan layer app dan juga membuat kode cantik. Kami juga mempunyai pelan untuk EOF. Walaupun saya agak, ia agak besar, tetapi saya melihat pentingnya kerana kode EOF sebenarnya lebih optimal untuk perkara seperti SP1, jadi akhirnya, saya rasa hampir segera, SoLady akan mempunyai EOF.

Ia tidak akan menjadi jenis yang berbeza. Jadi kita mempunyai direktri sumber quite soon, Solady will have an EOF. It won't be a breaking chain. So we have a source directory, and then we have an EOF directory. So you can use either one.

We won't force you to use either EOF or the legacy. We'll give you an option. Okay, so here are some links. You can visit solady.org, which is a shortcut to Solady.

Or you can visit my GitHub or my ex. Sometimes I post like small Solady lessons on my ex. Okay, I think that's all for my talk. Thank you. Thank you, Victorize, for this talk.

I guess we have all now a better idea of how to leverage assembly, inline assembly in our code. In the meantime, we have plenty of time for questions. So if you have any, make sure to please send them through this QR code. I'll be starting with the first one on the leaderboard. Did assembly ever bite you in the butt?

Where vanilla Solitude would have been more safe? Okay, when I was starting out like maybe two years ago, I think the safe transfer leap forgot to clean some upper bits because I directly potted it from soulmate. But then someone spotted that bug. So these days, I am super paranoid about unclean, dirty upper bits. So it becomes like a second nature.

So I think recently it should be quite safe. All right, next one. When to use let and when to use mstore? Okay, let is a way menentukan variabel dalam pembinaan. Jika seperti katakan, bagaimana-bagaimana anda tidak boleh memaksa kompiler untuk mengganti jangkauan terlalu dalam, maka anda mungkin perlu menggunakan mStore untuk menggunakan ruang kacau untuk variabel sementara.

Tetapi anda paling mungkin hanya boleh menggunakan dua bahagian have to use mStore to use the scratch space for temporary variables. But you at most can only use two parts of the scratch space, like two slots, because the other slots are for other purpose, for important stuff. Next one, why do you prefer Solidity Inline Assembly over other low-level languages like Huff? Okay, so the thing about... I like Huff, but the benefit of Solidity is that it allows you to recycle your efforts.

And also, it allows you to generate more compact bytecode. For example, in Huff, the inline is really inline. But whereas in Solidity, if you have like 10 use, if your function is a giant chunk of bytecode and it's used like in 30 different places, you might not actually want to inline it every single time. Next one, at L2's call data with call data feedback function, I guess from Libzip, has greater gas versus non-compressed call data feedback function, I guess from LibZip, has greater gas versus non-compressed call data, but has slightly cheaper gas at L1. Is that correct?

What happens under the hood? Okay, this depends on your L2. Some L2s already forward the gas savings of compressed call data to the users. So if you use CD4BET on Optimism, you will most probably not be able to save any core data money. So if you're deep on OP stack, just don't use that.

When using assembly-based libraries, is there a higher likelihood that it is less compatible with future Solidity versions? I would? Saya akan mengatakan bahawa sebenarnya itu kurang kemungkinan kerana, contohnya jika anda melihat penyimpanan transien, Solidity mengimplementasikannya pada tahap pembinaan pertama, kemudian kemudian ia menjadi seperti perkara yang lebih tinggi. Jadi satu perkara yang perlu anda risaukan adalah bahawa Solidity mungkin ber in ways that the high-level parts interpret the memory slightly differently. So that you have to keep up with the change log.

Victoria also has a nice friend, a nice hat, and a panda on his hat. Do you want to show everyone? Yeah, I guess that helps you as well in coding. Next one, I guess how Sol-AD's features saturated? How many more libraries and functions do you plan to add?

Okay, I think right now we have mostly saturated. We have a lot of work to do to port to EOF. Especially the lib clone is going to be... But the Solidity team has actually much more stuff to do compared to me. Another one about Sol-AD.

Will the new Solidity compiler in Rust impact Sol-AD? I think this new Solidity compiler called Solr, they try to become like a feature parity with the official Solidity compiler. Like for example, in C++ you have Clang, you have GCC. I think we might go that route down the road. And if you are just writing in a high-level language, you don't need to care whether you use Clang or GCC.

All right, that wraps up for our Q&A session. Thank you very much for the questions and give a big round of applause for Vectorize.