Ця стаття зі статті, написаної CKB і передрукованої wublockchain. (Синопсис: Демонтаж стратегічних амбіцій Віталіка щодо реконструкції виконавчого рівня Ethereum за допомогою «RISC-V замість EVM») (Передісторію додано: EVM пора припинити роботу!) Віталік пропонує перейти на RISC-V, ZK proof performance можна підвищити більш ніж у 100 разів) Поява блокчейну зробило смарт-контракти краще впровадженими та розвиненими, а між блокчейном та смарт-контрактами є важлива роль: віртуальні машини. Концепція віртуальних машин була запропонована в шістдесятих роках минулого століття, а популярною вона стала лише в дев'яностих. У той час Інтернет охоплював багато різних операційних систем і браузерів, і якщо розробники хотіли створити додаток, їм потрібно було адаптуватися до всіх різних операційних систем. Як відомо, розробка додатків зараз поділяється на системи Android та Apple, і тоді ситуація була складнішою. Так уже повелося, що мова програмування Java стала популярною, і віртуальна машина, побудована Java, може зробити так, щоб програму потрібно було написати лише один раз, покладаючись на віртуальну машину Java, можна виконати на декількох платформах, тому запропонований на той момент слоган був таким: компілюй в одному місці, виконуй скрізь. Ми знаємо, що Біткойн не має віртуальної машини, тому що Біткойн повинен передати номер (тобто «Біткойн») з адреси А на адресу Б, а Ethereum запитує, чому виконання на блокчейні не може бути набором коду, який може реалізувати більш складні та різноманітні речі? Це те, що ми називаємо платформою смарт-контрактів, де всі вузли виконують один і той же код контракту і отримують абсолютно однаковий результат. У блокчейні віртуальна машина є середовищем виконання смарт-контракту, який є повноцінною комп'ютерною системою, яка може бути повністю ізольована від зовнішнього світу. Блокчейн викликає та виконує смарт-контракти через віртуальні машини та вимагає згоди всіх вузлів. У той час як вузли використовують різні системи, деякі машини 64-розрядні, деякі 32-розрядні, традиційна віртуальна машина Java терпить невелику різницю в результатах обчислень, але в блокчейні всі результати повинні бути однаковими, тому нова, дружня до блокчейну віртуальна машина необхідна. Ідеальна віртуальна машина блокчейну Дизайн віртуальної машини кожного блокчейн-проекту матиме свої власні художні пошуки та піде на компроміси на різних рівнях, переслідуючи багато функцій. Провівши багато досліджень, ми вважаємо, що ідеальна віртуальна машина блокчейну повинна виглядати так: Виконання досить детерміноване, при виклику одного і того ж входу смарт-контракту повинен бути повернутий той же вихідний результат, і вихідний результат не залежить від зовнішніх умов, таких як час і середовище виконання; Є достатня безпека під час виконання, а виконання віртуальної машини не впливає негативно на саму платформу; Досить гнучкий для оновлень, щоб блокчейн можна було модернізувати або додати до криптографічних алгоритмів, не проходячи хардфорк (згадайте біль оновлення за допомогою хардфорка Ethereum); Інформація достатньо прозора, щоб дозволити смарт-контракту, виконаному на віртуальній машині, реалізувати весь потенціал віртуальної машини; Механізм комісії досить розумний для того, щоб розрахунок споживання ресурсів під час виконання віртуальної машини був більш обґрунтованим і точним. Він може підтримувати компіляцію різними мовами, надаючи розробникам свободу розробляти та використовувати новітні технології. Перед проектуванням віртуальної машини Nervos CKB ми виявили, що багато блокчейн-проектів не використовували реальний набір інструкцій CPU для побудови власних віртуальних машин, вони вибрали WASM для створення власних віртуальних машин. Ми вважаємо за краще використовувати реальний набір інструкцій ЦП для побудови наших власних віртуальних машин, тому що в нижній частині будь-якої складної віртуальної машини операції повинні бути перетворені на сирі інструкції збірки для виконання операцій на центральному процесорі. Крім того, використання реального набору інструкцій процесора не вносить деяких семантичних обмежень на рівні проектування і не обмежує гнучкість віртуальної машини. Якщо провести недоречну аналогію, то для роботи з центральним процесором потрібна мовна система, а використання реального набору інструкцій процесора схоже на можливість «говорити» безпосередньо з центральним процесором за допомогою цієї мовної системи, що дуже зручно. В іншому випадку це все одно, що спочатку заговорити китайською, а потім перейти на англійську, яким би досконалим не був рівень перекладу, будуть певні відхилення та обмеження. За допомогою реального набору інструкцій CPU віртуальна машина може додавати будь-який тип структури даних або алгоритм за потреби, що може максимізувати можливості розробника написати будь-який контракт, який відповідає вимогам. Тому ми вирішили наважитися і створити власну віртуальну машину CKB-VM, використовуючи реальний набір інструкцій процесора. При виборі набору інструкцій CPU ми вибрали спрощений набір інструкцій з відкритим вихідним кодом RISC-V. RISC-V може задовольнити вимоги до реалізації від малопотужних малих мікропроцесорів до високопродуктивних процесорів центрів обробки даних (DC) і характеризується прозорістю, простотою, модульністю, широтою підтримки та зрілістю. Ці характеристики ідеально відповідають вимогам конструкції CKB-VM. Отже, що таке RISC-V? RISC-V RISC-V — це зрозуміла, мінімалістична архітектура набору інструкцій процесора з відкритим вихідним кодом, створена в Каліфорнійському університеті в Берклі. У 2010 році, у зв'язку з обмеженнями інших комерційних наборів інструкцій із закритим вихідним кодом, дослідницька група університету розпочала новий проект і розробила новий набір інструкцій з відкритим вихідним кодом з нуля. Завдяки великій кількості регістрів і прозорій швидкості виконання інструкцій, цей новий набір інструкцій допомагає компіляторам і програмістам комбінаторної мови перетворювати практичні важливі задачі в відповідний, ефективний код і містить менше 50 інструкцій. Цей набір інструкцій RISC-V. Коли архітектори проектували RISC-V, вони хотіли, щоб RISC-V ефективно працював на всіх обчислювальних пристроях. З моменту свого винаходу в 2010 році чистий дизайн RISC-V завоював широку підтримку з боку промисловості та наукових кіл і був улюблений спільнотою. Фонд RISC-V Розробка набору інструкцій RISC-V в першу чергу здійснюється Фондом RISC-V та спільнотою. Заснований у 2015 році, Фонд RISC-V є некомерційною організацією та першою відкритою, спільною спільнотою новаторів апаратного та програмного забезпечення. Наразі RISC-V Foundation налічує понад 235 членів, серед яких Google, Qualcomm, Apple, IBM, Tesla, Huawei та інші компанії. Учасники можуть брати участь у розробці та використанні специфікацій набору інструкцій RISC-V, а також брати участь у розробці відповідних апаратних та програмних екосистем. Завдяки своєму оптимізованому дизайну з відкритим вихідним кодом, RISC-V став популярним у таких академічних установах, як Каліфорнійський університет у Берклі, Массачусетський технологічний інститут, Прінстонський університет та Інститут обчислювальної техніки Китайської академії наук. Крім того, деякі державні установи, такі як уряд Індії та Шанхайська муніципальна комісія з економічної інформації, також рішуче підтримують розвиток проектів на основі RISC-V. Існуючий набір інструкцій RISC-V є дуже молодим набором інструкцій, тож які основні набори інструкцій до цього? В епоху ПК x86 є непохитним повелителем, x86 - це CISC (Complex Instruction Set Computer, складний набір команд ) і RISC (Reduced Instruction Set Computer. На відміну від ) скорочених наборів інструкцій, набори інструкцій CISC продовжують зростати в міру своєї еволюції. Як наслідок, витрати продовжують зростати, а продуктивність та енергоспоживання страждають. Крім того, довжина набору інструкцій CISC, час виконання...
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Технології》Що таке RISC-V, який просуває Віталік? Чому CKB-VM обирає RISC-V?
Ця стаття зі статті, написаної CKB і передрукованої wublockchain. (Синопсис: Демонтаж стратегічних амбіцій Віталіка щодо реконструкції виконавчого рівня Ethereum за допомогою «RISC-V замість EVM») (Передісторію додано: EVM пора припинити роботу!) Віталік пропонує перейти на RISC-V, ZK proof performance можна підвищити більш ніж у 100 разів) Поява блокчейну зробило смарт-контракти краще впровадженими та розвиненими, а між блокчейном та смарт-контрактами є важлива роль: віртуальні машини. Концепція віртуальних машин була запропонована в шістдесятих роках минулого століття, а популярною вона стала лише в дев'яностих. У той час Інтернет охоплював багато різних операційних систем і браузерів, і якщо розробники хотіли створити додаток, їм потрібно було адаптуватися до всіх різних операційних систем. Як відомо, розробка додатків зараз поділяється на системи Android та Apple, і тоді ситуація була складнішою. Так уже повелося, що мова програмування Java стала популярною, і віртуальна машина, побудована Java, може зробити так, щоб програму потрібно було написати лише один раз, покладаючись на віртуальну машину Java, можна виконати на декількох платформах, тому запропонований на той момент слоган був таким: компілюй в одному місці, виконуй скрізь. Ми знаємо, що Біткойн не має віртуальної машини, тому що Біткойн повинен передати номер (тобто «Біткойн») з адреси А на адресу Б, а Ethereum запитує, чому виконання на блокчейні не може бути набором коду, який може реалізувати більш складні та різноманітні речі? Це те, що ми називаємо платформою смарт-контрактів, де всі вузли виконують один і той же код контракту і отримують абсолютно однаковий результат. У блокчейні віртуальна машина є середовищем виконання смарт-контракту, який є повноцінною комп'ютерною системою, яка може бути повністю ізольована від зовнішнього світу. Блокчейн викликає та виконує смарт-контракти через віртуальні машини та вимагає згоди всіх вузлів. У той час як вузли використовують різні системи, деякі машини 64-розрядні, деякі 32-розрядні, традиційна віртуальна машина Java терпить невелику різницю в результатах обчислень, але в блокчейні всі результати повинні бути однаковими, тому нова, дружня до блокчейну віртуальна машина необхідна. Ідеальна віртуальна машина блокчейну Дизайн віртуальної машини кожного блокчейн-проекту матиме свої власні художні пошуки та піде на компроміси на різних рівнях, переслідуючи багато функцій. Провівши багато досліджень, ми вважаємо, що ідеальна віртуальна машина блокчейну повинна виглядати так: Виконання досить детерміноване, при виклику одного і того ж входу смарт-контракту повинен бути повернутий той же вихідний результат, і вихідний результат не залежить від зовнішніх умов, таких як час і середовище виконання; Є достатня безпека під час виконання, а виконання віртуальної машини не впливає негативно на саму платформу; Досить гнучкий для оновлень, щоб блокчейн можна було модернізувати або додати до криптографічних алгоритмів, не проходячи хардфорк (згадайте біль оновлення за допомогою хардфорка Ethereum); Інформація достатньо прозора, щоб дозволити смарт-контракту, виконаному на віртуальній машині, реалізувати весь потенціал віртуальної машини; Механізм комісії досить розумний для того, щоб розрахунок споживання ресурсів під час виконання віртуальної машини був більш обґрунтованим і точним. Він може підтримувати компіляцію різними мовами, надаючи розробникам свободу розробляти та використовувати новітні технології. Перед проектуванням віртуальної машини Nervos CKB ми виявили, що багато блокчейн-проектів не використовували реальний набір інструкцій CPU для побудови власних віртуальних машин, вони вибрали WASM для створення власних віртуальних машин. Ми вважаємо за краще використовувати реальний набір інструкцій ЦП для побудови наших власних віртуальних машин, тому що в нижній частині будь-якої складної віртуальної машини операції повинні бути перетворені на сирі інструкції збірки для виконання операцій на центральному процесорі. Крім того, використання реального набору інструкцій процесора не вносить деяких семантичних обмежень на рівні проектування і не обмежує гнучкість віртуальної машини. Якщо провести недоречну аналогію, то для роботи з центральним процесором потрібна мовна система, а використання реального набору інструкцій процесора схоже на можливість «говорити» безпосередньо з центральним процесором за допомогою цієї мовної системи, що дуже зручно. В іншому випадку це все одно, що спочатку заговорити китайською, а потім перейти на англійську, яким би досконалим не був рівень перекладу, будуть певні відхилення та обмеження. За допомогою реального набору інструкцій CPU віртуальна машина може додавати будь-який тип структури даних або алгоритм за потреби, що може максимізувати можливості розробника написати будь-який контракт, який відповідає вимогам. Тому ми вирішили наважитися і створити власну віртуальну машину CKB-VM, використовуючи реальний набір інструкцій процесора. При виборі набору інструкцій CPU ми вибрали спрощений набір інструкцій з відкритим вихідним кодом RISC-V. RISC-V може задовольнити вимоги до реалізації від малопотужних малих мікропроцесорів до високопродуктивних процесорів центрів обробки даних (DC) і характеризується прозорістю, простотою, модульністю, широтою підтримки та зрілістю. Ці характеристики ідеально відповідають вимогам конструкції CKB-VM. Отже, що таке RISC-V? RISC-V RISC-V — це зрозуміла, мінімалістична архітектура набору інструкцій процесора з відкритим вихідним кодом, створена в Каліфорнійському університеті в Берклі. У 2010 році, у зв'язку з обмеженнями інших комерційних наборів інструкцій із закритим вихідним кодом, дослідницька група університету розпочала новий проект і розробила новий набір інструкцій з відкритим вихідним кодом з нуля. Завдяки великій кількості регістрів і прозорій швидкості виконання інструкцій, цей новий набір інструкцій допомагає компіляторам і програмістам комбінаторної мови перетворювати практичні важливі задачі в відповідний, ефективний код і містить менше 50 інструкцій. Цей набір інструкцій RISC-V. Коли архітектори проектували RISC-V, вони хотіли, щоб RISC-V ефективно працював на всіх обчислювальних пристроях. З моменту свого винаходу в 2010 році чистий дизайн RISC-V завоював широку підтримку з боку промисловості та наукових кіл і був улюблений спільнотою. Фонд RISC-V Розробка набору інструкцій RISC-V в першу чергу здійснюється Фондом RISC-V та спільнотою. Заснований у 2015 році, Фонд RISC-V є некомерційною організацією та першою відкритою, спільною спільнотою новаторів апаратного та програмного забезпечення. Наразі RISC-V Foundation налічує понад 235 членів, серед яких Google, Qualcomm, Apple, IBM, Tesla, Huawei та інші компанії. Учасники можуть брати участь у розробці та використанні специфікацій набору інструкцій RISC-V, а також брати участь у розробці відповідних апаратних та програмних екосистем. Завдяки своєму оптимізованому дизайну з відкритим вихідним кодом, RISC-V став популярним у таких академічних установах, як Каліфорнійський університет у Берклі, Массачусетський технологічний інститут, Прінстонський університет та Інститут обчислювальної техніки Китайської академії наук. Крім того, деякі державні установи, такі як уряд Індії та Шанхайська муніципальна комісія з економічної інформації, також рішуче підтримують розвиток проектів на основі RISC-V. Існуючий набір інструкцій RISC-V є дуже молодим набором інструкцій, тож які основні набори інструкцій до цього? В епоху ПК x86 є непохитним повелителем, x86 - це CISC (Complex Instruction Set Computer, складний набір команд ) і RISC (Reduced Instruction Set Computer. На відміну від ) скорочених наборів інструкцій, набори інструкцій CISC продовжують зростати в міру своєї еволюції. Як наслідок, витрати продовжують зростати, а продуктивність та енергоспоживання страждають. Крім того, довжина набору інструкцій CISC, час виконання...