Англійська для розумних контрактів Solidity

Обговорення прозорості мають реальні фінансові ставки, тому точний словник навколо вартості (газ) і безпеки (реєстрація) має більше значення, ніж у більшості бекендів - неясний опис помилки в розумному контракті може бути різницею між ловлею експлойта і відправкою одного.

Ключовий словник

Gas — одиниця вимірювання обчислювальної вартості операції на Ethereum, яку оплачує відправник транзакції, що робить кожен цикл, запис у сховище і зовнішній виклик рішенням про вартість, а не лише про продуктивність. “Ціна газу цієї функції змінюється з довжиною масиву, що означає, що в кінцевому підсумку її виклик стане занадто дорогим, оскільки масив зростає — нам потрібна інша структура даних.”

** Повторне входження ** — уразливість, за якої зовнішній виклик контракту, перед тим, як викликана функція завершить оновлення свого стану, повертає виклик до початкового контракту і використовує застарілий стан. “Ця функція виведення коштів уразлива до повторного входу, оскільки вона надсилає кошти до оновлення балансу — резервна функція атакуючого може викликати їх назад і витягувати їх неодноразово.”

** Модифікаційний код ** — частина коду, яку можна використовувати повторно, наприклад, onlyOwner, яка обгортає функцію, щоб виконати попередню умову перед її виконанням, утримуючи логіку контролю доступу поза самою функцією. “Додати модифікатор onlyOwner до цієї функції замість повторення перевірки власника вручну — це ідіомний спосіб виразити цю передумову.”

Upgradeability (proxy pattern) — шаблон проектування, який відокремлює зберігання контракту від його логіки, дозволяючи логічний контракт обмінюватися, а зберігання і адреса залишаються тими ж, оскільки розгорнутий байткод в іншому випадку незмінний. “Оскільки цей контракт не знаходиться за проксі, ми не можемо виправити помилку після розгортання — нам доведеться перенести користувачів на цілком нову адресу контракту.”

** Checks- Effects- Interactions ** — рекомендований шаблон перевірки умов, потім оновлення внутрішнього стану, і тільки потім здійснення зовнішніх викликів, зокрема, для запобігання експлуатацій у стилі реентрації. “Переупорядкувати цю функцію, щоб вона виконувала перевірки-ефекти-інтеракції — оновити баланс перед викликом .transfer(), а не після.”

Звичайні фрази

• «Яка газова вартість цього циклу при реальних розмірах масиву, а не тільки в тестовому випадку?»
• «Чи вразлива ця функція до реентрації — чи викликає вона перед тим, як закінчить оновлення стану?»
• Чи має ця передумова бути власним модифікатором замість вбудованих require-заяви?
• Чи є цей контракт оновлюваний, або постійна логіка після розгортання?
• Чи слідує ця функція за перевірками-ефективами-інтеракціями, або зовнішній виклик відбувається занадто рано?

Приклади висловлювань

Позначити проблему безпеки під час перегляду: “Це класичний шаблон повторного входження — зовнішній .call() відбувається перед оновленням стану, тому контракт нападника може знову ввійти і вийти кілька разів в одній транзакції.”

Пояснення оптимізації газу:

• “Ми перенесли цю перевірку у модифікатор і кешували довжину масиву поза петлею, що значно зменшило витрати на газ для звичайного випадку.” *

Обговорення рішення про розгортання: “Ми розгортаємо за проксі, щоб ми могли залатати цю логіку, якщо аудит виявить проблему після запуску, без необхідності мігрувати баланс кожного користувача на нову адресу.”

Професійні поради

• Кількісне вираження газової вартості конкретно в коментарях до огляду — «це дорого» є неясним, тоді як «газова вартість цього циклу зростає лінійно з довжиною масиву» говорить автору точно, що виправити.
• Назва ** reentrancy ** явно при флагінг конкретного зовнішнього виклику-перед-стан-оновлення шаблону - це єдиний найбільш послідовний словник слова в розумний контракт безпеки перегляду.
• Рекомендуємо checks-effects-interactions як виправлення, а не просто “переупорядкування вашого коду” - надання назви шаблону показує, що рецензент розпізнає його як встановлений захист, а не ad hoc думку.
• Роз’ ясніть, чи є контракт ** оновлюваним ** на початку будь- якого обговорення графіка виправлення помилок — це фундаментально змінює, чи буде виправлення відправлено за декілька годин, чи потребує повної міграції.

Практичні вправи

1. Пояснити, що робить функцію вразливою до реентрації в одному реченні.
2. Описати, чому вартість газу, а не тільки коректність, має значення при перегляді циклу у Solidity.
3. Напишіть речення, у якому пояснюється, що шаблон проксі- сервера робить для того, щоб дозволити оновлення.

На практиці: Навігація нюанс для не-рідних мовців

Перехід до професійної англійської мови в технічній галузі, такій як Solidity, може бути приголомшливим. Це не просто про знання * слів * - це розуміння того, як ці слова використовуються в конкретних контекстах, особливо при спілкуванні з досвідченими розробниками і зацікавленими сторонами. Для нерідних носіїв це часто означає боротьбу з тонкими відмінностями у фразуваннях, які можуть значно змінити значення або вплинути на сприйняття. Розглянемо декілька типових сценаріїв, де точність є найважливішою.

Одна з найчастіших проблем виникає під час перегляду коду. Коментар на кшталт «Ця функція може бути більш ефективною з точки зору використання газу» може здатися простим, але за ним часто слідує запит на пояснення: «Чи можете ви розібратися, * чому * це неефективно? Які конкретні області споживають найбільше газу?” У оригінальному заяві не вистачає інформації, яка могла б бути використана. Краще формулювання, спрямоване на ясність і співпрацю, було б: «Я бачу підвищені витрати на газ в цій функції. Зокрема, виклик transfer() робить значний внесок — можливо, ми могли б дослідити використання більш ефективного методу, такого як send() або розглянути пакетні транзакції, якщо це можливо.” Аналогічно, повідомлення Slack, що обговорюють PR, часто вимагають ретельно обраної мови, щоб уникнути непорозумінь. «Я реалізував функцію можливості оновлення, як описано в документі проекту» технічно коректно, але не має впливу. «Ця PR вводить необхідну логіку можливості оновлення розумного контракту, відповідно до специфікацій, описаних у doc-ID # 427» негайно надає важливий контекст і точку відліку для подальшого обговорення.

Інша область труднощів часто полягає у використанні технічного жаргону при поясненні складних концепцій нетехнічним зацікавленим сторонам. Переклад термінів, таких як «реентранці» або «делегативний виклик» на доступну мову є критичним, але навіть здавалося б прості пояснення можуть бути неправильно інтерпретовані, якщо не ретельно розроблені. Замість того, щоб сказати: «Цей контракт має вразливість з поверненням», можна сказати: «Існує потенційний ризик, що зовнішній контракт може перервати виконання цієї функції і спричинити непередбачені наслідки». Ця фраза підкреслює ризик, а не просто визначає технічну помилку, оформлюючи її в термінах, зрозумілих для когось без глибокого розуміння внутрішніх процесів Solidity.

Крім того, звертаючи увагу на модальні дієслова - “слід”, “може”, “може” - є ключовим для вираження невизначеності або рекомендацій в документації коду і описах PR. Використання «Цей договір * повинен * реалізувати… » передбачає зобов’язання, тоді як «Цей договір * може * отримати користь від … » передбачає можливість без накладання вимоги. Ці тонкі відмінності можуть кардинально змінити тон і вплив вашого спілкування.

Ось простий приклад, який показує, як використовувати вбудовану у forge оцінку газу:

forge build --source my_contract.sol --gas-limit 200000

Після виконання цієї команди буде автоматично обчислено витрати на збирання і розгортання вашого розумного контракту. Зрозуміти вихід з forge, особливо газовий ліміт і оцінене використання газу, є ключем до оптимізації вашого коду для ефективності - навички, що безпосередньо перекладається на ефективне спілкування про проблеми продуктивності під час перегляду коду.