Контракт консенсусного выполнения VDS и Ончейн-процесс

[JK 0]

Описание Контракта консенсусного выполнения

Фундаментальное понятие

Контракт консенсусного выполнения, то есть смарт-контракт. Команда VDS    считает “Смарт-контракт” за маркетинговый термин, потому что до сих пор мы не поняли, насколько умна технология контрактного программирования, это всего лишь предустановленная консенсусная программа, сформированная посредством редактирования кода в децентрализованной распределенной сети. В практическом духе научного исследования мы считаем, что более уместно переименовать “Смарт-контракт” в “Контракт консенсусного выполнения”, это может отражать суть децентрализованного консенсусного соглашения, а также устранить барьеры для понимания термина, когда люди объединяют технологию блокчейна с искусственной Интеллектуальной техникой в будущем.

Контракт консенсусного выполнения может применяться во многих сферах, таких как финансы, образование, административные системы, Интернет вещей, онлайн-развлечения. Посредством предварительного редактирования кода в конкретной распределенной сети сценарий реализуется без какого-либо стороннего вмешательства, чтобы достичь консенсуса всех сторон, участвующих в протоколе, с помощью технологии цепочки блоков. Это может гарантировать безопасное, стабильное и справедливое выполнение прав и интересов всех участников договора.

Для развития блокчейн-индустрии Контракт консенсусного выполнения может ускорить посадку различных приложений и привлечь все больше и больше разработчиков. Это революционизировало реальный опыт продукта технологии блокчейна. Все кредиты связаны с выдающимся вкладом команды Ethereum, которая открыла новые двери для всей отрасли.

 

Основная структура и точка зацепления

Интеграция EVM

EVM использует 256-битный машинный код. Это виртуальный механизм, основанный на стеке, который используется для выполнения консенсусных контрактов Ethereum. Поскольку EVM предназначен для системы Ethereum, для передачи значения используется Модель учетной записи Ethereum. Сеть VDS разработана на основе модели UTXO блокчейна. С одной стороны, это можно реализовать функцию резонансной торговли VDS, то есть функцию одностороннего перекрестного обмена с биткойна на VDS, где два разных адреса биткойна и VDS могут быть совместно пользоваться одним приватным  ключом. С другой стороны, команда VDS считает, что основная структура транзакций Биткойна более стабильна и надежна после социальной практики за 10 лет. Поэтому VDS использует Уровень абстракции учетной записи (Account Abstraction Layer) для преобразования модели UTXO в модель учетной записи, которая может быть выполнена EVM. Кроме того, VDS добавил интерфейс на основе модели учетной записи, таким образом EVM может считывать информацию непосредственно в цепочке VDS. Следует отметить, что Уровень абстракции учетной записи может скрывать подробности развертывания определенных конкретных функций и создавать разделение интересов для повышения функциональной совместимости и независимости платформы.

В системе Биткойна можно выполнять соответствующий вывод транзакции только после проверки Script Sig и Script Pub Key.

Например, Script Sig обычно блокирует вывод транзакции на адрес Биткойна (хэш открытого ключа). Только при условии соответствия условий Scig Sig и Script Pub Key комбинированный сценарий отобразит результат как верно (системное возвращаемое значение 1), так что будет выполнен соответствующий вывод транзакции.

А в распределенной системе VDS мы больше подчеркиваем своевременность для выполнения контракта и поэтому мы в Script Sig добавили операторы OP_CREATE и OP_CALL. Когда система VDS обнаружит эти операторы, мастерноды всей сети выполнят транзакцию. Таким образом, скрипт Биткойн не только служит в качестве языка кодирования, но и может отправить соответствующие данные в EVM. Так же, как Ethereum запускает Контракт консенсусного выполнения, операторы OP_CREATE и OP_CALL проводят контракт в действие, и EVM будет изменить состоянии в их соответствующих базах данных состояний.

Учитывая простоту для использования Контракта консенсусного выполнения VDS, необходимо проверить данные для отпирания контракта, и хэш открытого ключа источника данных.

Чтобы предотвратить UTXO занимать слишком большую часть в цепочке VDS, выходные данные транзакций OP_CREATE и OP_CALL также спроектированы как расходуемые, а выходные данные OP_CALL могут отправлять средства для других контрактов или адресов с открытым ключом.

Во-первых, для создания в цепочке VDS Контракта консенсусного выполнения система будет генерировать хэш транзакции. Новый контракт имеет начальный баланс 0 (контракты с ненулевым начальным балансом не поддерживаются). VDS использует оператор OP_CALL для создания вывода транзакции для отправки денег. Выходной скрипт контракта отправляющего фонда похож на:

   1: the version of the VM

    10000: gas limit for the transaction

    100: gas price in Qtum satoshis

    0xF012: data to send to the contract (usually using the solidity ABI)

    0x1452b22265803b201ac1f8bb25840cb70afe3303:

    ripemd-160 hash of the contract txid OP_CALL 

Этот скрипт не сложен, OP_CALL выполняет большую часть необходимой работы. VDS определяет конкретные издержки транзакции в Output Value, то  есть Gas Limit (не считая out-of-gas). Конкретный Gas-механизм будет обсуждать в следующих главах. Когда вышеупомянутый выходной скрипт добавляется в блокчейн, этот выход установит соответствующие отношения со счетом контракта и отразится в балансе контракта. Баланс может восприниматься в расходуемую сумму для контракта.

Стандартный вывод адреса с открытым ключом и хэш-кодом используется для основного процесса транзакций по контракту, и процессы транзакций между контрактами обычно согласованы. Кроме того, транзакции также могут выполнены через P2SH и нестандартные транзакции (non-standard transactions). В процессе транзакции расходуемый выход в этой учетной записи контракта будет использован. Эта потребляемая часть выхода используется для проверки транзакции в сети VDS и должна существовать. Мы называем это “Ожидаемой контрактной транзакцией”(Expected Contract Transactions). Поскольку ожидаемая контрактная транзакция происходит в процессе совершения проверки майнера и выполнения транзакции, и не будут транслироваться по всей сети.

Ожидаемая контрактная транзакция достигается с помощью кода OP_SPEND. OP_CREATE и OP_CALL имеют два режима работы: когда оператор действует как выходной скрипт, выполняются EVM. Когда оператор действует как входной скрипт, EVM не будет выполняться (в противном случае это вызовет повторное выполнение), в этом случае OP_CREATE и OP_CALL могут рассматриваться как операции без инструкций. OP_CREATE и OP_CALL получают хеш-значение транзакции, переданное OP_SPEND, и возвращают 1 или 0 (расходуемые или не расходуемые). Это показывает важность OP_SPEND во всех ожидаемых контрактных сделках. В частности, когда OP_SPEND передает хеш-значение транзакции в OP_CREATE и OP_CALL, OP_CREATE и OP_CALL сравнивают, существует ли хеш-значение в списке ожидаемых контрактных транзакций. Если он существует, верните 1, чтобы потратить; в противном случае вернуть 0, который не расходуется. Эта логика косвенно обеспечивает полный и безопасный способ осквернить, что договорные средства могут использоваться только по договору, что согласуется с выводом общих транзакций UTXO.

Когда контракты EVM отправляют средства на адрес с открытым ключом и  хэш-кодом или на другой контракт, новая транзакция будет установлена. Использует алгоритм Consensus-critical coin picking, наиболее подходящий вывод транзакции может быть выбран из доступного пула выхода контракта. Выбранные выходные данные транзакции будут использоваться в качестве входного сценария для выполнения одного OP_SPEND, выходные данные являются целевым адресом средств, а оставшиеся средства будут отправлены обратно в контракты при изменении выходных данных, доступных для потребления. Затем хеш-значение этой транзакции будет добавлено в список ожидаемых контрактных транзакций. Транзакция будет добавлена в блок сразу после ее выполнения. Когда майнеры в цепочке проверит и выполнят эту транзакцию, список ожидаемых контрактных транзакций будет снова пройден. Значение хеша будет удалено из списка после правильной проверки. Таким образом, использование OP_SPEND может эффективно предотвратить использование жестко закодированных значений хеш-функции для изменения стоимости вывода.

Уровень абстракции учетной записи (Account Abstraction Layer)  VDS позволяет EVM совершать денежные операции с другими контрактами и даже с адресами с открытым ключом и хэш-кодом, не обращая слишком много внимания на сбор монет, просто зная баланс в контрактах. Таким образом, требуется лишь подкорректировать Контракт консенсусного выполнения ethereum и можно  удовлетворить требования к работе контракта VDS.

Другими словами, все Контракты консенсусного выполнения ethereum  могут применяться к цепочке VDS.

Завершение AAL

Сеть VDS разработана на основе модели UTXO Биткойна. Платформы Контрактов консенсусного выполнения обычно используют модель счета, для всех контрактов требуется сетевой идентификатор, который является адресом контрактов, по этому работа и управление Контрактов консенсусного выполнения можно совершать посредством этого адреса. Уровень абстракции учетной записи (Account Abstraction Layer, AAL) добавляется в проект модели цепочки VDS, который используется для преобразования модели UTXO в модель счета, которая может быть выполнена по контракту.

Модель счетов для виртуальной машины относительно проста для разработчиков Контракта консенсусного выполнения. Модель поддерживает запрос баланса контрактов, а также может отправлять средства на другие контракты. Хотя эти операции кажутся очень простыми и базовыми, все транзакции в цепочке VDS используют язык сценариев Биткойн, и его сложнее, чем предполагалось, реализовать на уровне абстракции учетных записей в цепочке VDS на основе модели Bitcoin UTXO. Поэтому AAL расширился на этой основе и добавил три новых оператора:

OP_CREATE используется для создания интеллектуального контракта, передачи байт-кода, переданного транзакцией, в базу данных хранилища контрактов виртуальной машины и создания учетной записи контракта.

OP_CALL используется для передачи соответствующих данных и информации об адресе, необходимых для вызова по контракту, и для выполнения кода контракта (этот оператор также может отправлять деньги за согласованные контракты на выполнение)

OP_SPEND принимает значение хеш-функции текущего идентификатора контракта в качестве входной транзакции HASH или транзакции HASH, отправленной в UTXO контракта, а затем использует OP_SPEND в качестве инструкции по расходам для построения сценария транзакции.

 

Использование контракта и Ончейн-процесс 

 

Составлять контракт

В настоящее время можно использовать язык Solidity для составления Контракта консенсусного выполнения.

Используйте solidity remix или другую Solidity IDE для редактирования и компиляции кода.

solidity remix（https://remix.ethereum.org/）

Рекомендуем использовать модель homestead на редактирование.

Рекомендуем использовать версию solidity 0.4.24 (другие версии могут привести к ошибкам или сбоям).

Справочная ссылка грамматики Solidity（https://solidity.readthedocs.io/en)

ByteCode и ABI будут получены после компиляции.

 

Компилирование и развертывание контракта

Работа смарт-контракта vdsd

переменная величина среды тестирования

vdsd -txindex = 1 -logevents = 1 -record-log-opcodes = 1 -regtest = 1

> Контрактное тестирование проводится в тестовой среде. Рекомендуется проводить испытания после 440-й высоты блока.

Возврат средств и возврат после ненормальных событий контракта завершены на 440-й блок-высоте

 

Команды для развертывания контракта:

```vds-cli deploycontract bytecode ABI parameters```

- bytecode (string, required) contract bytecode.

- ABI  (string, required) ABI String must be JSON formatted.

- parameters (string, required) a JSON array of parameters.

 

Эта функция используется для выполнения конструктора контракта с входящими параметрами для получения ByteCode, который в конечном итоге используется для развертывания.

(Этот метод должен связать ByteCode с ABI и сохранить его локально для записи, где внутренний метод может быть вызван для возврата соответствующего байт-кода)

 

```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```

- bytecode (string, required) contract bytecode.

- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.

- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.

- senderaddress (string, optional) The vds address that will be used to create the contract.

- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.

- changeToSender (bool, optional, default=true) Return the change to the sender.

 

Возврат: txid, отправитель, hash160 отправителя, адрес контракта

 

Проверить выполнена ли команда:

```vds-cli gettransactionreceipt txid``` 

 

Возвращаемое значение txid для неконтрактных контрагентов пусто

 

Возвращаемое значение: соответствующая информация о txid в цепочке на этот раз

 

• BlockHash: блочный хэш
• blockNumber: высота блока
• transactionHash: хэш транзакции
• transactionIndex: идентификатор местоположения блока транзакции
• hash160 from адреса отправителя
• на адрес договора получателя, договорная сделка создается в 00000000000000000000000000000
• cumulativeGasUsed: совокупное использование Gas
• gasUsed: фактическое использование Gas
• contractAddress: адрес контракта
• excepted: если есть какая-либо ошибка
• exceptedMessage: ошибка сообщения

 

Следует отметить, что если поле исключений не равно None, выполнение контракта завершится неудачно. Хотя транзакции можно проверить в цепочке, это не указывает на успешное выполнение контракта, то есть плата за обработку для выполнения не возвращается. Он возвращается только тогда, когда внутренние контракты вводятся методом возврата, а не методом подтверждения.

 

Вызов контракта

```vds-cli addcontract name contractaddress ABI decription```

- name (string required) contract name.

- contractaddress (string required) contract address.

- ABI (string, required) ABI String must be JSON formatted.

- description (string, optional) The description to this contract.

Эта функция используется для добавления ABI контракта в локальную базу данных.

 

```vds-cli getcontractinfo contractaddress```

- contractaddress (string required) contract address.

Эта функция используется для получения информацию о контрактах, которые были добавлены.

 

```vds-cli callcontractfunc contractaddress function parameters```

- contractaddress (string, required) The contract address that will receive the funds and data.

- function (string, required) The contract function.

- parameters (string, required) a JSON array of parameters.

Эта функция вернет результат выполнения при вызове обычного константного метода, вызов метода операции с данными контракта вернет строку шестнадцатеричного формата сценария операции.

 

```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```

- contractaddress (string, required) The contract address that will receive the funds and data.

- datahex         (string, required) data to send.

- amount          (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0

- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.

- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.

- senderaddress (string, optional) The vds address that will be used to create the contract.

- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.

- changeToSender (bool, optional, default=true) Return the change to the sender.

Эта функция используется для отправки сценария операции контракта в указанный контракт и внесения его в блокчейн.

 

Проверить результаты исполнения контракта

```vds-cli gettransaction txid```

Эта команда используется для просмотра времени подтверждения текущих транзакций кошелька.

 

```vds-cli gettransactionreceipt txid```

Эта команда используется для проверки результатов выполнения создания контракта и вызова транзакции, определения наличия генерируемых исключений и фактического использования GAS.

 

`${datadir}/vmExecLogs.json` будет записывать контрактные вызовы на блокчейне. Этот файл будет служить внешним интерфейсом для событий контракта.

 

 

Интерфейсы вызова контракта

 

• Интерфейс создания контракта: createcontract
• Интерфейс развертывания контракта: deploycontract
• Добавить интерфейс ABI: addcontract
• Контрактный вызов с интерфейсом операции фонда: sendtocontract
• Чтение контрактного интерфейса: callcontractfunc
• Интерфейс выполнения транзакции получения контракта: gettransactionreceipt

 

 

Описание учета издержек контракта

Затраты на создание контракта вычислены расчетной оценкой, нет гарантии 100% успешного выполнения, потому что максимальный лимит gas limit — 50 000 000. Даже если вы отправите много gas, майнеры не будут использовать их все, они вернут оставшийся gas. Так что не беспокойтесь о том, чтобы тратить слишком много gas.

Общие издержки для создания контракта принимает размер Byte Code * 300, в качестве gas limit, минимальная gas price составляет 0,0000004, gas price * gas limit - это изрержки для создания контракта.

Что касается реализации определенных контракта, то необходим требуемый gas, что не может гарантировать 100% успеха ончейн из-за перегрузки сети. Чтобы не вводить в заблуждение, разработчики должны сами проверить результаты.