Подробнее о разных платформах для смарт контрактов
Мы живем в эпоху смарт контрактов. Возможно, Биткоин и продемонстрировал, что платежная система может существовать в одноранговой сети. Но именно появление Эфириума открыло эпоху блокчейна второго поколения, и люди наконец увидели настоящий потенциал децентрализованных приложений (далее dapps от англ. decentralized application) и смарт контрактов.
Подробнее о разных платформах для смарт контрактов
В этом гиде мы разберем несколько платформ для смарт контрактов и посмотрим, чем они отличаются друг от друга. Одни уже функционируют, другие - в процессе разработки. Прежде чем приступить, давайте ответим на один вопрос.
Что именно представляют из себя смарт контракты?
Смарт контракты - это автоматизированные контракты. Они содержат точные инструкции в коде, которые при соблюдении определенных условий выполняются автоматически.
Узнать больше о смарт контрактах можно в нашем детальном гиде.
Итак, что мы хотим от смарт контракта?
Все, что функционирует на блокчейне, должно быть неизменным и работать на многочисленных нодах без ущерба технического состояния. Соответственно, функционал смарт контракта должен обладать следующими свойствами:
- Детерминированность.
- Завершаемость.
- Изолированность.
Фича №1: Детерминированность
Программа считается детерминированной при условии, что каждый раз выдает один и тот же результат на одни и те же входные данные. Например, если 3+1 = 4, то 3+1 ВСЕГДА равняется 4. Когда программа дает тот же результат на один и тот же набор входных данных на разных компьютерах, она называется детерминированной.
Есть несколько случаев, когда программа может работать недетерминированным образом:
- Вызов недетерминированных системных функций: когда программист вызывает недетерминированное функции в программе.
- Недетерминированные источники информации: если программа получает данные во время работы, а источник данных недетерминирован, тогда и программа становится недетерминированной. Допустим, программа получает на определенный запрос топ 10 гугл ответов. Этот список может меняться.
- Динамические вызовы: когда одна программа вызывает вторую, это называется динамическим вызовом. Поскольку цель вызова определяется только во время выполнения, она не детерминирована по своей природе.
Фича №2: Завершаемость
В математической логике есть ошибка под названием “проблема остановки”. По сути она состоит в том, что невозможно знать выполнит ли программа свою функцию за заданный лимит времени. В 1936 году Алан Тьюринг, используя диагональный метод Кантора, пришел к выводу, что способов узнать, уложится ли программа в срок, нет.
Это, очевидно, представляет проблему для смарт контрактов, потому что они по определению должны завершаться за определенный лимит времени. Было предпринято несколько мер, чтобы гарантировать возможность завершить контракт извне и не попасть в бесконечный цикл, который будет истощать ресурсы:
- Неполнота по Тьюрингу: неполный по Тьюрингу блокчейн будет иметь ограниченный функционал и не сможет совершать скачки и/или попасть в бесконечный цикл. В результате попасть в бесконечный цикл контракты не смогут;
- Счетчик шагов и выплат: программа может просто вести счет числа предпринятых “шагов”, т.е. числа выполненных инструкций, и затем завершаться как только было выполнено определенное количество шагов. Другой способ - счетчик комиссий, когда контракты выполняются с предоплатой. За выполнение каждой инструкции взимается определенная плата. Если расходы превышают предоплаченную сумму, контракт завершается;
- Таймер, когда соблюдается заранее заданный тайминг. Если выполнение контракта превышает лимит времени, то он завершается извне.
Фича №3: Изолированность
Любой может загрузить смарт контракт в блокчейн. По этой причине контракты могут умышленно или по ошибке содержать вирусы и баги.
Если контракт не изолирован, он может навредить всей системе. Следовательно, чтобы уберечь всю экосистему от любых вредных воздействий, крайне важно изолировать контракт в “песочнице”.
Сейчас, когда мы рассмотрели эти фичи, важно узнать, как они реализуются на практике. Обычно смарт контракты работают, используя одну из двух систем:
- Виртуальные машины: их используют Эфириум и Нео
- Docker: его использует Fabric.
Давайте их сравним и определим, какая больше подходит для экосистемы. Чтобы не усложнять, сравним Эфириум (виртуальная машина) с Fabric (Docker).
Итак, как видите, Виртуальные Машины предоставляют более детерминированную, ограниченную по сроку и изолированную среду для смарт контрактов.
Сейчас мы знаем, что из себя представляют смарт контракты, и что виртуальные машины больше подходят на роль платформы для смарт контрактов. Давайте взглянем на то, что именно требуется для эффективной работы децентрализованных приложений.
Что требуется для работы децентрализованных приложений?
Или, выражаясь точнее, какими минимальными требованиями должно обладать децентрализованное приложение, чтобы снискать успех у широкой аудитории?
Поддержка миллионов пользователей
Оно должно быть достаточно масштабируемым, чтобы миллионы пользователей могли его использовать. Это особенно актуально для приложений, которые хотят внедрить в массы.
Бесплатное использование
Платформа должна давать разработчикам возможность создавать бесплатные приложения для своих пользователей. Пользователь не должен платить за использование приложения.
Легкость модернизации
Возможность для разработчиков апгрейдить приложение по желанию. Также если какие-либо баги влияют на приложение, разработчики должны иметь возможность доработать приложение, не влияя на работу самой платформы.
Минимальная задержка
Приложение должно работать максимально бесперебойно и с минимально допустимой задержкой.
Параллельное выполнение
Возможность параллельной обработки приложений, чтобы распределять нагрузку и экономить время.
Последовательное выполнение
Однако, не все функции на блокчейне должны выполняться параллельно. Представьте себе транзакцию. Нельзя параллельно выполнять большое количество транзакций; нужно выполнять их по очереди во избежание ошибок типа двойного расходования.
Итак, какие платформы мы можем использовать для создания децентрализованных приложений?
У BitShares и Graphene хорошая пропускная способность, но они явно не подходят для смарт контрактов. Эфириум - самый очевидный выбор на рынке. У них потрясающие возможности для смарт контрактов, но есть большая проблема в виде низкой скорости транзакций. Кроме того, цена Gas также может стать проблемой.
Теперь мы знаем, что требуется для работы децентрализованных приложений. Давайте рассмотрим несколько платформ для смарт контрактов:
- Ethereum;
- EOS;
- Stellar;
- Cardano;
- Neo;
- Hyperledger Fabric.
Эфириум
Во-первых, у нас есть Эфириум, с которого все началось.
Вот какое определение Эфириума дает их сайт:
“Эфириум - это децентрализованная платформа для смарт контрактов: приложения, которые работают в точности с задумкой без малейшей вероятности простоя, цензуры, мошенничества или вмешательства третьей стороны. Они работают на специально приспособленным для этого блокчейне, невероятно мощной общедоступной глобальной инфраструктуре, которая может передавать ценности и олицетворять право собственности”
Проще говоря, Эфириум планируют стать основной программной платформой будущего. Если в будущем будет царить децентрализация, а децентрализованные приложения станут обыденностью, то Эфириум выйдет на первый план.
EVM ( от англ. Ethereum virtual machine - виртуальная машина Эфириум) - это виртуальная машина, в которой все смарт контракты функционируют на Эфириум. Это простая и в то же время мощная полная по Тьюрингу 256-битная виртуальная машина. Полная по Тьюрингу, значит, что любая программа, выполненная на EVM, учитывая ресурсы и память, может решить любую задачу.
Чтобы писать коды смарт контрактов в EVM, нужно выучить язык программирования Solidity.
Solidity - намеренно сокращенный язык со слабой типизацией и синтаксисом очень похожим на ECMAScript (Javascript). В “Обоснования принятых проектных решений” Эфириум есть несколько ключевых моментов, которые стоит запомнить, а именно то, что мы работаем в рамках модели стековой памяти с размером командного слова в 32 байта; EVM дает доступ к “стеку” программы, который похож на регистр, где мы также можем прикрепить адреса блока памяти для перехода Счетчика программы (для последовательного программного управления); расширяемая временная “память” и более постоянное “хранилище”, которое написано в постоянном блокчейне; самое важное - полная детерминированность смарт контрактов.
Прежде чем мы продолжим, давайте взглянем на простой пример контракта на Solidity (коды взяты с github).
Простой while-цикл на Solidity:
contract BasicIterator
{
address creator; // reserve one "address"-type spot
uint8[10] integers; // reserve a chunk of storage for 10 8-bit unsigned integers in an array
function BasicIterator()
{
creator = msg.sender;
uint8 x = 0;
//Section 1: Assigning values
while(x < integers.length) {
integers[x] = x;
x++;
} }
function getSum() constant returns (uint) {
uint8 sum = 0;
uint8 x = 0;
//Section 2: Adding the integers in an array.
while(x < integers.length) {
sum = sum + integers[x];
x++;
}
return sum;
}
// Section 3: Killing the contract
function kill()
{
if (msg.sender == creator)
{
suicide(creator);
}
}
}Проанализируем код. Мы разделили код на 3 раздела для удобства понимания.
Раздел 1: присвоение значений
В первом шаге мы заполняем массив под названием “целые числа”, который включает 10 8 битных беззнаковых целых чисел. Мы делаем это через while-цикл. Давайте посмотрим, что происходит внутри while-цикла.
while(x < integers.length) {
integers[x] = x;
x++;
}Помните, что мы уже присвоили значение “0” целому числу x. While-цикл отсчитывает от 0 до integers.length. Integers.length - это функция, которая возвращает максимальную вместимость массива. Если мы решим, что в массиве будет 10 целых чисел, arrayname.length вернет значение 10. В цикле выше значение x длится от 0 – 9 (<10) и присваивает свое значение целым числам массива. В конце цикла целые числа будут иметь следующее значение:
0,1,2,3,4,5,6,7,8,9.
Раздел 2: добавление наполнения массива
Внутри функции getSum() мы добавим наполнение самого массива. Мы сделаем это с помощью повторения такого же while-цикла как выше и использования переменной “sum”, чтобы добавить наполнение массива.
Раздел 3: Прекращение контракта
Эта функция прекращает контракт и отправляет оставшиеся средства в контракте обратно его создателю.
Что такое Gas?
Gas - источник жизненной силы экосистемы Эфириум, иначе не скажешь. Gas - это единица, которая измеряет количество вычислительных затрат для выполнения определенных операций.
Для совершения любой операции в Эфириум, будь то простая транзакция или смарт контракт, или даже ICO, нужно некоторое количество Gas. Gas используется, чтобы вычислить количество комиссий, которые нужно выплатить для выполнения операции.
Когда кто-то заключает смарт контракт, он имеет предопределенную стоимость Gas. Для выполнения каждого шага контракта требуется определенное количества Gas.
Вариантов развития событий два:
- Необходимое количество Gas превышает установленный лимит. В таком случае в контракт приходит в первоначальное состояние, и весь Gas расходуется.
- Необходимое количество Gas меньше, чем установленный лимит. В таком случае контракт выполняется, и оставшийся Gas передается установившему контракт.
Эфириум, возможно, и проложили дорогу для смарт контрактов, но у них есть проблемы с масштабируемостью. Тем не менее такие инновации как plasma, raiden, sharding и т.д. могут их решить.
EOS
EOS нацелены на то, чтобы стать децентрализованной операционной системой, которая сможет поддерживать децентрализованные приложения в производственных масштабах.
Звучит это довольно круто, но по-настоящему захватили воображение публики следующие два заявления:
- Они планируют полностью убрать комиссии за транзакции.
- Они заявляют о том, что у них есть возможности проводить миллионы транзакций в секунду.
Именно эти фичи вызвали неподдельный интерес разработчиков децентрализованных приложений. Давайте посмотрим, как EOS реализуют их на практике.
Отсутствие комиссий
EOS работает на модели долевого участия, согласно которой пользователи имеют право использовать ресурсы пропорционально своей доле. Если у вас N токенов EOS, вы можете провести N*k транзакций, что сводит на нет комиссии за транзакции.
Цена Gas за запуск и размещение приложений на Эфириум на ранних этапах разработки может быть достаточно высокой и отпугнуть новых разработчиков.
Основное различие между Эфириум и EOS в том, что Эфириум дают в аренду свои вычислительные мощности разработчикам, а EOS предоставляют свои ресурсы в качестве собственности. Если вы владеете 1/1000 доли в EOS, у вас во владении будет 1/1000 вычислительной мощности и ресурсов EOS.
Как утверждают в обзоре ICO:
Модель долевого участия EOS дает разработчикам dapps прогнозируемые цены на хостинг, требуется лишь соблюдать определенный процент или уровень доли, и дает возможность создавать условно бесплатные приложения. Более того, поскольку держатели EOS смогут давать в аренду/делегировать свою долю ресурсов другим разработчикам, эта модель привязывает стоимость токенов EOS к спросу и предложению пропускной способности и хранилища”.
Возросшая масштабируемость
Механизм консенсуса DPOS (Делегированное доказательство долей) обеспечивает масштабируемость. Он работает следующим образом:
Сначала, все кто хранит токены на блокчейне, интегрированном в ПО EOS, могут выбрать блок продюсеров с помощью системы голосования. Любой может участвовать в выборах. Возможность производить блоки будет дана пропорционально общему количеству полученных голосов по сравнению со всеми другими продюсерами.
Как это работает?
- Блоки производятся в раундах 21.
- В начале каждого цикла выбирается 21 блок продюсер. Топ 20 выбирается автоматически, а 21 выбирается пропорционально количеству голосов по сравнению с другими продюсерами.
- Затем продюсеры перемешиваются с помощью псевдослучайного числа, полученного из времени блока. Это делается, чтобы убедиться, что соблюдается баланс взаимосвязи с другими продюсерами.
- Чтобы гарантировать регулярное производство блоков и что время на производства блока составляет 3 секунды, за невыполнение обязательств продюсеров удаляют из кандидатов в производители блоков. Продюсер должен производить как минимум один блок каждые 24 часа, чтобы быть кандидатом.
Поскольку так мало людей вовлечены в консенсус, процесс происходит быстрее и более централизован чем в Эфириум и Биткоин, которые для консенсуса используют всю сеть.
Язык WASM
EOS использует язык программирования WebAssembly, он же WASM. Он используются в силу следующих свойств (взяты с webassembly.org):
- Скорость и эффективность: WASM исполняет на собственной скорости, используя преимущества стандартного оборудования доступные на множестве платформ.
- Открытый и поддающийся наладке: он создан, чтобы хорошо печататься в текстовом формате для устранения багов, тестирования, экспериментов, оптимизации, обучения и написания программ вручную.
- Безопасность: описывает среду, безопасную для памяти изолированное выполнение, даже может быть внедрено в существующие виртуальные машины JavaScript.
EOS - превосходная платформа для создания dapps в промышленных масштабах. Давайте представим, что вы создаете децентрализованный Твиттер. Если бы вы создали его на Эфириум, тогда пользователям пришлось бы потратить некоторое количество Gas на выполнение каждого шага.
Если бы вы сделали то же самое на EOS, пользователям не пришлось бы тратить Gas, потому что комиссий за транзакции нет. Однако, т.к. EOS не такой децентрализованный как Эфириум, dapps, которым нужна высокая устойчивость к цензуре, он может не подойти.
Stellar
Stellar - детище Джеда МакКалеба и Джойса Кима, был сформирован еще в 2014, когда был форком протокола Ripple. Stellar, согласно их веб-сайту,
“это платформа, которая соединяет банки, платежные системы и людей. Присоединяйтесь и переводите деньги быстро, надежно и практически бесплатно”.
Используя Stellar можно переводить деньги быстро, надежно и за копейки.
В отличие от Эфириум, смарт контракты Stellar (SSC) не полные по Тьюрингу.
С некоторыми параметрами вы можете столкнуться сразу же.
Самые примечательные - это время подтверждения в 5 секунд и стоимость одной транзакции всего лишь в $0,0000002!
$stellarNetwork->buildTransaction($customerKeypair)
->addCreateAccountOp($escrowKeypair, 100.00006) // 100 XLM after setup fees + transfer transaction
->submit($customerKeypair);
}
print "Created escrow account: " . $escrowKeypair->getPublicKey() . PHP_EOL;
/*
* In order to make this an escrow account, we need to prove to the worker that
* no one is able to withdraw funds from it while the worker is searching for
* a vanity address.
*
* This is accomplished by:
* - Making the worker and customer signers of equal weight (1)
* - Requiring both signers to agree on any transaction (thresholds are set to 2)
*
* However, we also need to handle the case where no worker takes the job and we
* need to reclaim the account. This can be done by adding a preauthorized merge
* transaction that's not valid until 30 days from now.
*
* This allows the worker to know that the funds are guaranteed to be available
* for 30 days.
*/
// Load up the escrow account
$account = $stellarNetwork->getAccount($escrowKeypair);
// Precalculate some sequence numbers since they're necessary for transactions
$startingSequenceNumber = $account->getSequence();
// Track how many transactions are necessary to set up the escrow account
// We need this so we can correctly calculate the "reclaim account" sequence number
$numSetupTransactions = 5;
$reclaimAccountOrPaySeqNum = $startingSequenceNumber + $numSetupTransactions + 1;
// Update the account with a data value indicating what vanity address to search for
print "Adding data entry to request a vanity address...";
$stellarNetwork->buildTransaction($escrowKeypair)
->setAccountData('request:generateVanityAddress', 'G*ZULU')
->submit($escrowKeypair);
print "DONE" . PHP_EOL;
// Fallback transaction: reclaim the escrow account if no workers generate the
// vanity address in 30 days
$reclaimTx = $stellarNetwork->buildTransaction($escrowKeypair)
->setSequenceNumber(new BigInteger($reclaimAccountOrPaySeqNum))
// todo: uncomment this out in a real implementation
//->setLowerTimebound(new \DateTime('+30 days'))
->setAccountData('request:generateVanityAddress')
->addMergeOperation($customerKeypair)
->getTransactionEnvelope();
// Add hash of $reclaimTx as a signer on the account
// See: https://www.stellar.org/developers/guides/concepts/multi-sig.html#pre-authorized-transaction
$txHashSigner = new Signer(
SignerKey::fromPreauthorizedHash($reclaimTx->getHash()),
2 // weight must be enough so no other signers are needed
);
$addReclaimTxSignerOp = new SetOptionsOp();
$addReclaimTxSignerOp->updateSigner($txHashSigner);
print "Adding pre-authorized reclaim transaction as a signer... ";
$stellarNetwork->buildTransaction($escrowKeypair)
->addOperation($addReclaimTxSignerOp)
->submit($escrowKeypair);
print "DONE" . PHP_EOL;
print "Added pre-auth reclaim transaction valid at sequence " . $reclaimAccountOrPaySeqNum . PHP_EOL;
print "To reclaim the escrow account, run 90-reclaim-escrow.php" . PHP_EOL;
// Add worker account as a signer of weight 1
$workerSigner = new Signer(
SignerKey::fromKeypair($workerKeypair),
1 // requires another signer
);
$addSignerOp = new SetOptionsOp();
$addSignerOp->updateSigner($workerSigner);
$stellarNetwork->buildTransaction($escrowKeypair)
->addOperation($addSignerOp)
->submit($escrowKeypair);
// Add customer account as second signer of weight 1
$workerSigner = new Signer(
SignerKey::fromKeypair($customerKeypair),
1 // requires another signer
);
$addSignerOp = new SetOptionsOp();
$addSignerOp->updateSigner($workerSigner);
$stellarNetwork->buildTransaction($escrowKeypair)
->addOperation($addSignerOp)
->submit($escrowKeypair);
// Increase thresholds and set master weight to 0
// All operations now require threshold of 2
$thresholdsOp = new SetOptionsOp();
$thresholdsOp->setLowThreshold(2);
$thresholdsOp->setMediumThreshold(2);
$thresholdsOp->setHighThreshold(2);
$thresholdsOp->setMasterWeight(0);
$stellarNetwork->buildTransaction($escrowKeypair)
->addOperation($thresholdsOp)
->submit($escrowKeypair);
print PHP_EOL;
print "Finished configuring escrow account" . PHP_EOL;Кардано
Кардано - один из самых интересных недавно вышедших проектов. Как и Эфириум, Кардано - это платформа смарт контрактов, однако в отличии от Эфириум, Кардано предлагает масштабируемость и безопасность с помощью многоуровневой архитектуры. Подход Кардано сам по себе уникален, поскольку он построен на научной философии и проверенном научном исследовании.
Кардано стараются повысить масштабируемость с помощью их механизма консенсуса доказательства долей Уроборос. Чтобы писать смарт контракты в Кардано, нужно использовать Плутос, который основан на Хаскелле - языке на котором написан Кардано.
C++ и большинство традиционных языков программирования - императивные, а Плутос и Хаскелл - функциональные.
Как работает функциональное программирование?
Допустим, есть функция f(x), которую мы хотим использовать, чтобы посчитать функцию g(x), и затем мы хотим использовать ее для работы с функцией h(x)g(x). Вместо решения их всех друг за другом, мы можем просто собрать их всех вместе в одну функцию как эта:
h(g(f(x)))
Таким образом функциональный подход легче обосновать математически. Вот почему считается, что функциональные программы более безопасны, нежели создание смарт контрактов. Они также способствуют более простой формальной верификации. Это упрощает математическое доказательство того, что программа может, и придает Кардано свойство “Высоконадежного Кода”.
Давайте возьмем пример из жизни и посмотрим, почему это может стать крайне критичным и даже жизненно важным в определенных условиях.
Предположим, мы пишем программу, которая контролирует воздушные перевозки.
Как вы можете себе представить, написание кода для такой системы требует высокого уровня точности. Мы не может просто слепо копировать что-то и надеяться на лучшее, когда на кону жизни людей. В подобных ситуациях нам нужен код с высокой степенью математической точности.
Вот именно поэтому функциональный подход столь желателен.
Именно по этой причине Кардано использует Хаскелл для экосистемы, а Плутос - для смарт контрактов. И тот и другой - функциональные языки.
Следующая таблица сравнивает императивный подход с функциональным.
Давайте взглянем на преимущества функционального подхода:
- Способствует созданию кода высокой надежности в силу того, что математически легче доказать, как код поведет себя в дальнейшем.
- Повышает легкость чтения и сопровождения, поскольку каждая функция создана таким образом, чтобы выполнять определенное задание. Функции также не зависят от состояния системы.
- Код проще изменить, а любые изменения в коде - применить. Это упрощает итеративную разработку.
- Отдельные функции легко могут быть изолированы, что облегчает их тестирование и отладку.
Нео
Нео, ранее известный как Antshares часто называют “Китайским Эфириумом”.
Согласно их сайту Нео - некоммерческий территориальный проект, который использует технологию блокчейн и цифровую идентификацию личности, чтобы преобразовать активы в цифровую форму, автоматизировать управление цифровыми активами, используя смарт контракты, и реализовать “смарт экономику” с распределенной сетью”.
Главная цель Нео - стать распределенной сетью для “смарт экономики”.
Согласно их сайту:
Цифровые активы + цифровая идентификация личности + смарт контракт = смарт экономка.
Нео был разработан основанной в Шанхае блокчейн научно-производственной компанией “OnChain”. Onchain был основан генеральным директором Da Hongfei and CTO Erik Zhang. Исследование началось приблизительно в 2014 году. В 2016 году Onchain был в списке Топ 50 Финтех компаний Китая согласно KPMG.
Нео хотели создать платформу смарт контрактов, у которой будут все преимущества ВМ Эфириум, не обременяя своих разработчиков языковыми барьерами. Вам нужно выучить Solidity, чтобы писать смарт контракты в Эфириуме, а в Нео для этого можно использовать даже Javascript.
Смарт контракт Нео 2.0
Система смарт контрактов Нео она же Смарт контракт Нео 2.0 состоит из 3 частей:
- NeoVM.
- InteropService
- DevPack
NeoVm
Это графическое представление виртуальной машины Нео:
Изображение предоставлено Neo Whitepaper
Согласно whitepaper Нео, NeoVM - это легковесная, многофункциональная ВМ, чья архитектура очень напоминает JVM и .NET Runtime. Она похожа на виртуальную CPU, которая считывает и исполняет инструкции в контракте последовательно, логические операции и т.д. с хорошей скоростью запуска, которая делает ее великолепной средой для управления смарт контрактами.
InteropService
InteropService увеличивает функциональность смарт контрактов. Он дает контрактам доступ к данным вне NeoVM, не ставя под угрозу общую стабильность и эффективность системы.
В настоящее время уровень обслуживания предоставляет API для доступа к следующим данным цепи смарт контракта:
- Информация о блоках.
- Информация о транзакциях.
- Информация о контрактах.
- Информация об активах.
...наряду с некоторыми другими.
Он также предоставляет пространство для хранения смарт контрактов.
DevPack
Включает компилятор языка высокого уровня и IDE плагин. Архитектура NeoVM очень похожа на JVM and .NET Runtime, поэтому контракты можно писать на разных языках. Можете себе представить, как это сократило время на обучение созданию смарт контрактов.
Hyperledger Fabric
Согласно их сайту “Hyperledger - общедоступное продукт коллективного творчеста, созданный, чтобы продвинуть межотраслевые технологии блокчейн. Это глобальная коллаборация на базе Linux Foundation, включающая в себя лидеров в области финансов, банковского дела, Интернета вещей, системы снабжения, промышленности и технологии.”
Пожалуй, самый их интересный проект - IBM’s Fabric. Fabric не столько обособленный блокчейн, сколько плацдарм для развития решений на базе блокчейн с модульной архитектурой.
С разными компонентами блокчейна такими как консенсус, членство, Fabric, смогут соответствовать стандарту plug-and-play. Fabric создан для предоставления фреймворка, с помощью которого предприятия смогут объединить отдельные блокчейн сети, которые могут быстро масштабироваться до более чем 1000 транзакций в секунду.
Что такое Fabric и как она работает? Фреймворк внедрен в Go для консорциума блокчейнов с разными уровнями доспуа. Fabric сильно полагаются на систему смарт контрактов Chaincode, каждый пир сети которой функционирует в контейнерах Docker.
Чтоб написать Chaincode, вы дожны прекрасно разбираться в 4 функциях:
- PutState: создать новый актив или обновить уже существующий.
- GetState: восстановить актив.
- GetHistoryForKey: восстановить историю изменений.
- DelState: ‘удалить’ актив.
Ниже пример Chaincode:
// Define the Smart Contract structure
type SmartContract struct { }
// Define the car structure, with 4 properties.
type Car struct {
Make string `json:"make"`
Model string `json:"model"`
Colour string `json:"colour"`
Owner string `json:"owner"`
}
/*
* The Invoke method is called as a result of an application request to run the Smart Contract "fabcar"
* The calling application program has also specified the particular smart contract function to be called, with arguments
*/
func (s *SmartContract) Invoke(APIstub shim.ChaincodeStubInterface) sc.Response {
// Retrieve the requested Smart Contract function and arguments
function, args := APIstub.GetFunctionAndParameters()
// Route to the appropriate handler function to interact with the ledger appropriately
if function == "initLedger" {
return s.initLedger(APIstub)
} else if function == "createCar" {
return s.createCar(APIstub, args)
}
return shim.Error("Invalid Smart Contract function name.")
}
func (s *SmartContract) initLedger(APIstub shim.ChaincodeStubInterface) sc.Response {
return shim.Success([]byte("Ledger is now running, success!"))
}
// Add new car to database with obtained arguments
func (s *SmartContract) createCar(APIstub shim.ChaincodeStubInterface, args []string) sc.Response {
if len(args) != 5 {
return shim.Error("Incorrect number of arguments. Expecting 5")
}
var car = Car{Make: args[1], Model: args[2], Colour: args[3], Owner: args[4]}
carAsBytes, _ := json.Marshal(car)
APIstub.PutState(args[0], carAsBytes)
return shim.Success(nil)
}
func main() {
// Create a new Smart Contract
err := shim.Start(new(SmartContract))
if err != nil {
fmt.Printf("Error creating new Smart Contract: %s", err)
}
}Заключение
Итак, теперь вы знаете про различные уникальные свойства платформ для смарт контрактов. Универсальной платформы, по крайне мере на данный момент, нет. Выбирайте ту, которая больше других отвечает потребностям вашего децентрализованного приложения.
Оригинал статьи: https://blockgeeks.com/guides/different-smart-contract-platforms/