Засновник Ethereum V God запропонував замінити «RISC-V» на Ethereum на рівні виконання, щоб замінити минулий EVM, що викликало у деяких розробників підозри, а в 2016 році розробник Ethereum OG вважав, що це змусить екосистему Ethereum зіткнутися з перерозподілом і буде дуже недружньою до проектів з дрібним капіталом. (Синопсис: Плата за обробку Ethereum досягла п'ятирічного мінімуму, і спільнота запустила «теорію отрути L2»: на дорогах немає машин, а V God все ще сміється і будує шосе) (Довідкове доповнення: Демонтаж стратегічних амбіцій Віталіка щодо реконструкції виконавчого рівня Ethereum за допомогою «RISC-V замість EVM») Нещодавня пропозиція засновника Ethereum V God «RISC-V» привернула увагу криптоспільноти та викликала дебати серед розробників основної екосистеми, і більшість користувачів не можуть зрозуміти RISC-V Як реформувати Ethereum і який прогрес пропозиція V-God може принести Ethereum? Для того, щоб відповісти на це питання, ми взяли інтерв'ю у старого «антимасштабного дракона» OG, який розробляє основну екологію Ethereum з 2016 року, і він відповість на детальний процес перегляду «RISC-V» і короткострокові негативні наслідки, які можуть виникнути в майбутньому, нагадавши всім інвесторам Ethereum звернути пильну увагу на подальші дії цієї пропозиції. Як оновити ситуацію з RISC-V Ethereum відрізняється від інших ланцюжків PoS тим, що клієнт Ethereum складається з двох частин, «рівня консенсусу» та «рівня виконання», а рівень консенсусу відповідає за голосування за упаковку стейкінгу, а рівень виконання відповідає за обробку транзакцій, тому код, який виконує смарт-контракт, насправді є клієнтом рівня виконання, яким керує комп'ютер-вузол, який запускає код, захоплюючи трансляцію транзакції, і записує результати голосування через «рівень консенсусу» в публічний реєстр. Єдиний спосіб оновити поточне середовище EVM до RISC-V – це оновити «клієнт рівня виконання» клієнта вузла, який є лише форком програмного рівня, на відміну від звичайного хардфорку в минулому для зміни блоку Ethereum та відповідної версії вузла. Згідно з описом змісту статті V God, в ідеалі, якщо всі клієнти вузлів мають виконавці RISC-V, то робота протоколу для нової версії та робота доказу zk може досягти майже в 100 разів більшої теоретичної ефективності, але слід знати, що вона розраховується на смарт-контракті для версії RISC-V та клієнті RISC-V, щодо формату смарт-контракту EVM, що виконується на клієнті EVM. Що особливого в пропозиції RISC-V цього разу, так це те, що він безпосередньо оновлений на клієнті виконавчого рівня і не буде використовувати частину хардфорка, що мені не дуже подобається, але видно, що Ethereum рухається в новому напрямку, який може бути двосічним краєм, і цей рівень змін у минулому Ethereum може вирішити реалізувати за допомогою хардфорку, тому що це може бути безпечнішим підходом. Відповідність поточної ситуації та старому контракту Зрозумівши ефективність теорії, давайте подивимося, яка поточна ситуація, поточна ситуація полягає в тому, що вся екологія Ethereum і всі практики EIP успішно виконуються за допомогою смарт-контрактів EVM і клієнтів EVM, якщо, як сказав V God, що RISC-V матиме транспілер EVM, то фактичну майбутню ситуацію можна розділити на такі ситуації смарт-контракти EVM працюють на клієнті EVM (старий EIP повністю сумісний, але новий EIP повинен відповідати двом версіям) Смарт-контракт EVM працює на клієнті RISC-V через транспілер EVM RISC-V (для вирішення старого та нового EIP потрібно пройти багато тестування та налагодження) Смарт-контракт RISC-V працює на клієнті RISC-V (усі старі EIP будуть повторно протестовані, але новий EIP має бути ідеально сумісним) Таким чином, з огляду на теоретичну ефективність роботи майбутнього смарт-контракту в 100 разів, застосовним є лише третій стан, а для другого випадку, Зокрема, він покладається на оптимізацію транспілятора основною командою Ethereum, а також на всі оновлення EIP і смарт-контракти в минулому, а це означає, що Ethereum повинен заплатити дуже велику ціну оптимізації, щоб досягти теоретичного підвищення продуктивності, і невідомо, чи оптимізація ефективності старого коду EVM за допомогою трансляції на RISC-V безумовно більша, ніж у рідного середовища EVM. Насправді, V God сказав це, я думаю, що має бути багато основних розробників, які відчували себе дуже відчайдушно, в минулому на розробці EVM, щоб вирішити кожну реалізацію та тестування EIP, робоче навантаження вже дуже велике, тому що Ethereum - це спільнота, яка любить тестувати відкриті відповіді в дуже відкритому середовищі. Але тепер, коли це стає середовищем RISC-V, я просто думаю про тестовий період трансформації, що є дуже головним болем, основна проблема полягає в тому, що ви, можливо, не зможете запустити більш ніж в 1~5 разів ефективніше, ніж початкове середовище протягом тестового періоду, тому я думаю, що цей тестовий період продовжуватиметься багато разів, як і Ethereum Merge в минулому, так що на ранній стадії не вистачає конкретних результатів, і важко залучити зовнішні екосистеми для розгортання в тестовій мережі та надсилання відгуків. Я можу лише сказати, що V God має великі амбіції, але я не думаю, що реалізація дуже оптимістична, принаймні я думаю, що більше половини основних розробників можуть бути не дуже задоволені, якщо вони сповнені рішучості перейти на RISC-V, V GOD і Ethereum Foundation потрібно витратити багато зусиль, щоб заохотити основну команду розробників та екологію. Проблема екологічної відповідності RISC-V Дракон зазначив, що найбільшою проблемою пропозиції RISC-V може бути підтримка та відповідність приватного проекту екологія, в існуючій екосистемі з відкритим вихідним кодом компоненти, які можуть бути використані, дуже обмежені, тому слоган перекладу EVM на RISC-V, запропонований V God, може мати багато сумнівів і проблем у короткостроковій перспективі. Наприклад, існуюча екосистема Ethereum, така як EVM-проекти та контракти, які не мають проблем, за передумовою трансляції EVM на RISC-V може бути відсутність стану або припинення операцій у процесі виконання контракту на рівні виконання, а це означає, що навіть у старих EVM-проектах, які не мали жодних проблем у минулому, у разі використання трансляції EVM у RISC-V можуть виявитися токени, які не можуть бути запропоновані, або випадково спалені чи заблоковані. Такий приклад з великою ймовірністю призведе до того, що команда екологічного проекту, в деяких випадках, не захоче відкривати користувачам можливість використовувати транспілер EVM на RISC-V для запуску застарілих смарт-контрактів EVM; Крім того, щоб уникнути пов'язаних з цим ризиків і стежити за новою технологією Ethereum, найкращим способом для екосистеми проекту є написання нової версії контракту RISC-V для всіх смарт-контрактів, а зв'язок між старим контрактом і новим контрактом вирішується за допомогою мосту активів. Насправді, спосіб зайнятися сумісністю дуже простий в упаковці, але якщо фонд готовий розкидати гроші, щоб отримати загальне рішення, то він може вирішити 99% проблем сумісності, але проблема полягає в решті 1% і довірі екологічних забудовників. Тепер ви запитаєте розробників проекту Ethereum, я думаю, я не буду настільки впевнений у частині EVM-трансляції RISC-V, технологічні компанії з великим капіталом хочуть належати до своїх власних кастомних систем або чіпів від початку до кінця, вони не обов'язково виберуть RISC-V, тому що, хоча ця архітектура є відкритим вихідним кодом, порівняно з основними архітектурами, такими як ARM і X86, екологічна підтримка RISC-V дуже обмежена, і немає пов'язаного розвитку блокчейну, а це означає, що Ethereum повинен відкривати світ голими руками. Якщо на іспиті...
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ethereum "зміна RISC-V" лякає розробників? OG попереджає: екосистема ETH буде перерозподілена, маленькі проекти покинуть Solana
Засновник Ethereum V God запропонував замінити «RISC-V» на Ethereum на рівні виконання, щоб замінити минулий EVM, що викликало у деяких розробників підозри, а в 2016 році розробник Ethereum OG вважав, що це змусить екосистему Ethereum зіткнутися з перерозподілом і буде дуже недружньою до проектів з дрібним капіталом. (Синопсис: Плата за обробку Ethereum досягла п'ятирічного мінімуму, і спільнота запустила «теорію отрути L2»: на дорогах немає машин, а V God все ще сміється і будує шосе) (Довідкове доповнення: Демонтаж стратегічних амбіцій Віталіка щодо реконструкції виконавчого рівня Ethereum за допомогою «RISC-V замість EVM») Нещодавня пропозиція засновника Ethereum V God «RISC-V» привернула увагу криптоспільноти та викликала дебати серед розробників основної екосистеми, і більшість користувачів не можуть зрозуміти RISC-V Як реформувати Ethereum і який прогрес пропозиція V-God може принести Ethereum? Для того, щоб відповісти на це питання, ми взяли інтерв'ю у старого «антимасштабного дракона» OG, який розробляє основну екологію Ethereum з 2016 року, і він відповість на детальний процес перегляду «RISC-V» і короткострокові негативні наслідки, які можуть виникнути в майбутньому, нагадавши всім інвесторам Ethereum звернути пильну увагу на подальші дії цієї пропозиції. Як оновити ситуацію з RISC-V Ethereum відрізняється від інших ланцюжків PoS тим, що клієнт Ethereum складається з двох частин, «рівня консенсусу» та «рівня виконання», а рівень консенсусу відповідає за голосування за упаковку стейкінгу, а рівень виконання відповідає за обробку транзакцій, тому код, який виконує смарт-контракт, насправді є клієнтом рівня виконання, яким керує комп'ютер-вузол, який запускає код, захоплюючи трансляцію транзакції, і записує результати голосування через «рівень консенсусу» в публічний реєстр. Єдиний спосіб оновити поточне середовище EVM до RISC-V – це оновити «клієнт рівня виконання» клієнта вузла, який є лише форком програмного рівня, на відміну від звичайного хардфорку в минулому для зміни блоку Ethereum та відповідної версії вузла. Згідно з описом змісту статті V God, в ідеалі, якщо всі клієнти вузлів мають виконавці RISC-V, то робота протоколу для нової версії та робота доказу zk може досягти майже в 100 разів більшої теоретичної ефективності, але слід знати, що вона розраховується на смарт-контракті для версії RISC-V та клієнті RISC-V, щодо формату смарт-контракту EVM, що виконується на клієнті EVM. Що особливого в пропозиції RISC-V цього разу, так це те, що він безпосередньо оновлений на клієнті виконавчого рівня і не буде використовувати частину хардфорка, що мені не дуже подобається, але видно, що Ethereum рухається в новому напрямку, який може бути двосічним краєм, і цей рівень змін у минулому Ethereum може вирішити реалізувати за допомогою хардфорку, тому що це може бути безпечнішим підходом. Відповідність поточної ситуації та старому контракту Зрозумівши ефективність теорії, давайте подивимося, яка поточна ситуація, поточна ситуація полягає в тому, що вся екологія Ethereum і всі практики EIP успішно виконуються за допомогою смарт-контрактів EVM і клієнтів EVM, якщо, як сказав V God, що RISC-V матиме транспілер EVM, то фактичну майбутню ситуацію можна розділити на такі ситуації смарт-контракти EVM працюють на клієнті EVM (старий EIP повністю сумісний, але новий EIP повинен відповідати двом версіям) Смарт-контракт EVM працює на клієнті RISC-V через транспілер EVM RISC-V (для вирішення старого та нового EIP потрібно пройти багато тестування та налагодження) Смарт-контракт RISC-V працює на клієнті RISC-V (усі старі EIP будуть повторно протестовані, але новий EIP має бути ідеально сумісним) Таким чином, з огляду на теоретичну ефективність роботи майбутнього смарт-контракту в 100 разів, застосовним є лише третій стан, а для другого випадку, Зокрема, він покладається на оптимізацію транспілятора основною командою Ethereum, а також на всі оновлення EIP і смарт-контракти в минулому, а це означає, що Ethereum повинен заплатити дуже велику ціну оптимізації, щоб досягти теоретичного підвищення продуктивності, і невідомо, чи оптимізація ефективності старого коду EVM за допомогою трансляції на RISC-V безумовно більша, ніж у рідного середовища EVM. Насправді, V God сказав це, я думаю, що має бути багато основних розробників, які відчували себе дуже відчайдушно, в минулому на розробці EVM, щоб вирішити кожну реалізацію та тестування EIP, робоче навантаження вже дуже велике, тому що Ethereum - це спільнота, яка любить тестувати відкриті відповіді в дуже відкритому середовищі. Але тепер, коли це стає середовищем RISC-V, я просто думаю про тестовий період трансформації, що є дуже головним болем, основна проблема полягає в тому, що ви, можливо, не зможете запустити більш ніж в 1~5 разів ефективніше, ніж початкове середовище протягом тестового періоду, тому я думаю, що цей тестовий період продовжуватиметься багато разів, як і Ethereum Merge в минулому, так що на ранній стадії не вистачає конкретних результатів, і важко залучити зовнішні екосистеми для розгортання в тестовій мережі та надсилання відгуків. Я можу лише сказати, що V God має великі амбіції, але я не думаю, що реалізація дуже оптимістична, принаймні я думаю, що більше половини основних розробників можуть бути не дуже задоволені, якщо вони сповнені рішучості перейти на RISC-V, V GOD і Ethereum Foundation потрібно витратити багато зусиль, щоб заохотити основну команду розробників та екологію. Проблема екологічної відповідності RISC-V Дракон зазначив, що найбільшою проблемою пропозиції RISC-V може бути підтримка та відповідність приватного проекту екологія, в існуючій екосистемі з відкритим вихідним кодом компоненти, які можуть бути використані, дуже обмежені, тому слоган перекладу EVM на RISC-V, запропонований V God, може мати багато сумнівів і проблем у короткостроковій перспективі. Наприклад, існуюча екосистема Ethereum, така як EVM-проекти та контракти, які не мають проблем, за передумовою трансляції EVM на RISC-V може бути відсутність стану або припинення операцій у процесі виконання контракту на рівні виконання, а це означає, що навіть у старих EVM-проектах, які не мали жодних проблем у минулому, у разі використання трансляції EVM у RISC-V можуть виявитися токени, які не можуть бути запропоновані, або випадково спалені чи заблоковані. Такий приклад з великою ймовірністю призведе до того, що команда екологічного проекту, в деяких випадках, не захоче відкривати користувачам можливість використовувати транспілер EVM на RISC-V для запуску застарілих смарт-контрактів EVM; Крім того, щоб уникнути пов'язаних з цим ризиків і стежити за новою технологією Ethereum, найкращим способом для екосистеми проекту є написання нової версії контракту RISC-V для всіх смарт-контрактів, а зв'язок між старим контрактом і новим контрактом вирішується за допомогою мосту активів. Насправді, спосіб зайнятися сумісністю дуже простий в упаковці, але якщо фонд готовий розкидати гроші, щоб отримати загальне рішення, то він може вирішити 99% проблем сумісності, але проблема полягає в решті 1% і довірі екологічних забудовників. Тепер ви запитаєте розробників проекту Ethereum, я думаю, я не буду настільки впевнений у частині EVM-трансляції RISC-V, технологічні компанії з великим капіталом хочуть належати до своїх власних кастомних систем або чіпів від початку до кінця, вони не обов'язково виберуть RISC-V, тому що, хоча ця архітектура є відкритим вихідним кодом, порівняно з основними архітектурами, такими як ARM і X86, екологічна підтримка RISC-V дуже обмежена, і немає пов'язаного розвитку блокчейну, а це означає, що Ethereum повинен відкривати світ голими руками. Якщо на іспиті...