gakonst

Reth v1.5.0 da Ethereum bloklarini qayta ishlash tezligi 15-20% ga tezlashdi.

yana yangiliklar bor!

Nega bu CT bo‘yicha mashhur bo‘lmagan fikr bo‘lishi mumkinligini tushunmayman, lekin: men Uniswap yuk mashinasini zo‘r deb o‘ylayman.

Agar siz Reth muhandisi bo'lsangiz va rekruterlar bilan ishlayotgan bo'lsangiz, menga to'g'ridan-to'g'ri murojaat qilishingiz mumkin.

Biz Reth Engineer lavozimini kripto infratuzilmasining kelajagi uchun eng muhim rollardan biri sifatida yaratdik va portfelimizda juda ko‘p imkoniyatlar bor. Men sizni tanishtirib beraman.

Bitcoin hashrate hosilalari hisobidan stablecoin yaratish mumkinmi?

Foydalanuvchilar gaz to‘lovlarini to‘lamasligi kerak, ilovalar to‘lasin.

Portodagi to‘lovni homiylik qilish bo‘yicha NextJS namunasi yaqinda chiqdi (mavzudagi havola)

@Paradigm’dan yangilanish! 6-8 avgust SF.

2-kun 🔥🔥🔥 ko‘rinayapti.

1 ta emas, 2 ta emas, 3 ta — yuqori unumdorlik bo‘yicha ma’ruzalar!
- @ashekhirin va @Rjected tomonidan "Hyperoptimizing Reth"
- @brianisbland tomonidan “Scaling Ethereum's State Trie”
- @adietrichs tomonidan "Scaling Ethereum L1".

Quyidagiga amal qiling!

Hozir eng tez katlanadigan / IVC SNARK qaysi?

Uning optimallashtirilgan implementatsiyasi bormi?

Ish isbotiga asoslangan blokcheynlarda ulushga asoslangan yakuniylik gadjetlari bo‘yicha konsensusli mutaxassis qidiryapman, agar foydali ish isboti / MEV bozori tuzilmasini ham o‘rgangan bo‘lsangiz, qo‘shimcha ball

Agar mening kripto ijtimoiy grafigim dunyoda voqealar bo‘layotganda texnik qolsa yoki demokratik va tinchlikni targ‘ib qiluvchi fikrlar bilan band bo‘lsa, juda zo‘r bo‘lardi. Kripto global erkinlik va tinchlik uchun texnologiya bo‘lishi kerakku.

Glamsterdam’da Ethereum’ning g‘alaba qozonishiga oxir-oqibat yordam bermaydigan narsalar: EOF, EVM64, SSZ/pureth, Mavjud attestatsiyalar.

Hozirga kelib kuchli hujum kerak, zaif hujum emas va albatta uzoq muddatli mudofaa ham emas. Qisqa muddatli mudofaa (masalan, repricinglar) esa yaxshi.

RE: Ethereum’ning EL qismida nima bo‘lishi kerak, mening hozirgi fikrim:
- Fusaka eng oson yondashuv bo‘lib, gaz limitini oshirishga cheklov (cap) qo‘yadi.
- Glamsterdam esa yuqoridagi gaz limitini oshirishni davom ettiradi va eng yomon holatlar ehtimolini cheklash uchun (repricing orqali) qayta narxlashni amalga oshiradi.

Mening g‘alati taxminim shuki, Glamsterdamdan keyin, keyingi repricing va gaz limitini oshirishlardan tashqari, EL’ni ZK (nol bilimli) foydalanish uchun optimallashtirishga o‘tish kerak — bu nimani anglatishini qanday bo‘lsa ham.

Fusaka bu yil bo‘lib o‘tadi va L2’larning yanada kengayishiga yordam beradi.

Ishga tushirish vaqtida bloblar o‘zgarmaydi, faqat oldindan rejalashtirilgan blob-only forklar bilan ular 48 tagacha, umid qilamizki, 2026 yilning 1-choragida ko‘tariladi.

Biz o‘lchashda davom etamiz va qanchagacha yetishimiz mumkinligini ko‘ramiz; vositalar tayyor, hozir faqat amaliyot (reps) kerak.

Biz AI-dan unumdorligimizni oshirish va ochiq manba hamjamiyatini qo‘llab-quvvatlash uchun foydalanishda tobora yaxshilanayapmiz.

Ushbu PR’da biz Claude muvaffaqiyatli tarzda Forge Lint’ uchun (forge build’da sukut bo‘yicha ishga tushadi) past darajali EVM call checker’ni yaratgan promptlarni ulashamiz.

https://github.com/foundry-rs/foundry/pull/10810

Mening fikrimcha, global tugunlar to‘plamini saqlagan holda Ethereum yutishi uchun muhim bo‘lgan narsa:

1. butun jarayon davomida zk yordamida validatsiyani bloklarni yaratishdan ajratib qo‘yish. buning uchun zk bilan bloklarni real vaqt rejimida isbotlashni osonroq qilish kerak: ePBS yoki Delayed Execution — qaysi biri muhim emas. trie migratsiyalari yordam berishi mumkin, lekin menimcha shart emas, holbuki slot oxirida emas, balki boshida isbotlashni ta’minlash juda muhim.

2. eng zaif tugundan ajratib, tsenzuraga chidamlilikni (censorship resistance) ta’minlash. Agar yuqoridagilarni qilsangiz, FOCIL bilan past-ETH ulushli tugunlarni (faqat CR uchun mas’ul, lekin hot path blok yaratish va validatsiya uchun emas) joriy qilish bizni masshtablash uchun Raspberry Pi’dan ozod qiladi, lekin CR uchun Raspberry Pi’lardan foydalanishda davom etishimizga imkon beradi

Mening fikrimcha, Ethereum g‘alaba qozonishi uchun global tugunlar tarmog‘ini saqlagan holda eng muhim narsa nimalar:

1. butun jarayon davomida (blok tuzishdan) validatsiyani zk orqali ajratish. bu zk bilan bloklarni real vaqt rejimida isbotlashni osonroq qilishni talab qiladi: ePBS yoki Delayed Execution — qaysi biri ekanligi muhim emas. trie migratsiyalari yordam berishi mumkin, lekin meningcha shart emas; eng muhim jihat — slot oxirida emas, balki boshida isbotlashga erishish.

2. tsenzuraga chidamlilikni eng zaif tugundan ajratish. Agar yuqoridagilar qilinsa, past miqdorda-ETH garovga qo‘yilgan tugunlarni joriy etish mumkin: ular faqat CR uchun javobgar bo‘ladi, lekin blok tuzish va validatsiyaning “hot path” qismida qatnashmaydi. Bu bizni masshtablash uchun “raspberry pi”lardan xalos qiladi, lekin CR uchun ularni ishlatishda davom etishimizga imkon beradi

Men Ethereum Core Dev hamjamiyati Solidity Lang so‘rovi bo‘yicha EVM ishlab chiquvchilari eng ko‘p tilga olgan 2 ta muammoni tuzatishni birinchi o‘ringa qo‘ymasligidan hali ham hayronman, takror-takror harakat qilganimizga qaramay:

1. Stack too Deep: ha, bu Solidity’ning mahorat muammosi biroz, lekin shunchaki SWAP/DUP17-32 opcode diapazonini qo‘shib, bas. Siz opkodlarni bir oz yoqasiz. Mayli, ular ishlatilishi uchun yaratilgan. Siz yana PUSH0 uslubidagi mos kelmaslikka duch kelasiz, bu ham bo‘laveradi, mukammal emas, lekin baribir bo‘ladi.

2. 24KB limitni olib tashlang. Qilgan ishingiz menga unchalik muhim emas: 32KB qiling, 48KB qiling, 128KB, 256KB, 512KB—hammasini birdaniga qiling, bosqichma-bosqich. Narxini belgilangmi yoki yo‘qmi, farqi yo‘q, lekin nimadir qiling! Hozir, kelasi yil emas!

Agar siz L1 ni kengaytirayotgan bo‘lsangiz, odamlar ahmoqona xatolarsiz kontrakt yozishini ta’minlash P0.

Agar tizim 10 yil oldin aynan shunday parametr qilib belgilangan bytecode uchun har bytecode’ga qo‘shimcha 8KB ni ham ko‘tara olmasa, L1 ni haqiqatan ham kengaytirib bera olishingizga umuman imkon yo‘q.

Stack too deep va bytecode hajmi limitini tuzating! Dasturchilar uchun!

Men hali ham hayratdaman: Ethereum Core Dev hamjamiyati Solidity Lang so‘rovida qayd etilgan EVM ishlab chiquvchilari uchun eng ko‘p keltirilgan 2 ta muammoni birinchi o‘ringa qo‘ymaydi:

1. Stack too Deep: ha, bu Solidity mahorat muammosi — biroz. Lekin shunchaki SWAP/DUP17-32 opcode diapazonini qo‘shib, masalani hal qiling. Siz biroz opcode sarflaysiz. Baribir, ular ishlatilishi uchun yaratilgan. Sizda yana PUSH0 uslubidagi nomuvofiqlik chiqadi — bu ham mayli, mukammal emas, lekin mayli.

2. 24KB limitni olib tashlang. Nima qilsangiz ham mayli: 32KB, 48KB, 128KB, 256KB, 512KB qiling — barchasini birdan qiling, bosqichma-bosqich ham bo‘ladimi — farqi yo‘q. Narxini qo‘ying yoki qo‘ymang, lekin biror narsa qiling! Hozir, keyingi yil emas!

Agar siz L1 ni kengaytirayotgan bo‘lsangiz, odamlar bema’ni xatolarsiz kontrakt yozishi mumkinligini ta’minlash — P0.

Agar tizim 10 yil oldin o‘rnatilgan parametr bo‘lgan bytekod uchun qo‘shimcha 8KB ni ham boshqara olmasa, unda siz L1 ni haqiqatan kengaytira olishingizga umuman imkon yo‘q.

Stack too deep va bytekod hajmi limitini tuzating! Dasturchilar uchun!

Ethereum Core Dev hamjamiyati Solidity Lang so‘rovi bo‘yicha EVM dasturchilarining eng ko‘p tilga olingan muammosini tuzatishga ustuvorlik bermasligidan hali ham hayronman.

1. Stack too Deep: ha, bu Solidity bo‘yicha mahorat muammosi biroz, lekin shunchaki SWAP/DUP17-32 opcode diapazonini qo‘shib, bas. Siz biroz opcode yoqasiz. Mayli, ular ishlatilishi uchun-ku. Sizda PUSH0 uslubidagi mos kelmaslik yana paydo bo‘ladi — bu ham mayli, mukammal emas, lekin baribir mayli.

2. 24KB limitni olib tashlang. Nima qilsangiz ham mayli: 32KB, 48KB, 128KB, 256KB, 512KB qiling — barchasini birdaniga, bosqichma-bosqich ham qilavering; narxini qo‘ying-yo‘qmi — farqi yo‘q, lekin nimadir qiling! Hozir! Keyingi yilda emas!

Agar siz L1 ni kengaytirayotgan bo‘lsangiz, odamlarga ahmoqona xatolarsiz kontrakt yozishga imkon berish P0.

Agar tizim literal 10 yil oldin o‘rnatilgan parametr bo‘lgan bytecode uchun har bir bytecodega qo‘shimcha 8KB ni ko‘tara olmasa, L1 ni haqiqatan kengaytirishning ham imkoni yo‘q.

Stack too deep va bytecode hajmi limitini tuzating! Dasturchilar uchun!

Har bir kripto infratuzilmasi qandaydir tarzda baribir Reth bilan bog‘lanadi.

Uning muvaffaqiyati uchun eng muhim omil — OSS hamjamiyati. Reth’ga hissa qo‘shgan va uning vizioniga hamda uzoq muddatli muvaffaqiyatiga sodiq bo‘lgan >500 dan ortiq geo-tarqoq odamlar tayyorlangan jamoasi.

Texnik jihatdan esa Reth loyihasi 3 ta ustundan iborat:
- Xavfsizlik: Ethereum L1’ni ishlab chiqarish staking muhitlarida qo‘llab-quvvatlash orqali. O‘yinda ulush.
- Ishlash: L2 va MEV bloklar yaratishda frontni oldinga surish orqali. Terragas.
- Moslashuvchanlik: fork qilmasdan tuguningizni modding qilish uchun ajoyib API’larni taqdim etamiz. Reth SDK.

Yana juda ko‘p ishlar bor, lekin bugungi kunda qayerga yetganimizdan haqiqatan ham faxrlanamiz.