Lisk станет полноценной средой разработки DApp для создания и распространения децентрализованных приложений. В настоящее время он находится на стадии краудфандинга, но также был добавлен в стек Microsoft Blockchain-as-a-Service.
Он рекламирует, что вы можете создавать децентрализованные приложения, просто написав Javascript. Но поскольку вы также можете создавать JS-DApps для Ethereum, интересно, в чем разница?
Предупреждение, я не большой поклонник Lisk. Это, очевидно, одна сторона истории, и я уверен, что у Lisk больше преимуществ, чем я считаю. Но я их не знаю.
Основные моменты автора относительно Lisk:
«Песочница» Lisk не может использоваться для запуска ненадежного кода
Платформа Lisk не обеспечивает защиты от недетерминированного поведения.
У Lisk нет возможности предотвратить бесконечные циклы и/или измерить общий объем вычислений.
Lisk не может предотвратить неограниченный рост памяти и/или измерить потребление памяти.
Общие функции языка JavaScript (такие как итерация по ключам в объекте) результаты скрыты недетерминированное поведение
Основные тезисы автора относительно ETH:
Ethereum защищает разработчиков от бесчисленных проблем, с которыми сталкиваются опытные разработчики блокчейнов.
Изучение синтаксиса нового языка тривиально по сравнению с изучением того, как избежать миллионов способов, которыми вы можете выстрелить себе в ногу.
Приложения Ethereum не имеют возможности генерировать недетерминированное поведение.
Нет необходимости управлять состоянием «отменить» в Ethereum, потому что любое выброшенное исключение автоматически откатывает все изменения (кроме комиссии).
.
Lisk: Javascript против Ethereum: go, C++, rust, Solidity, Serpent и т. д.
Лиск
Одной из вещей, которую Lisk активно продвигала перед предпродажей, был тот факт, что их Dapp написан на Javascript, «самом популярном языке в мире». Фактически, они позиционировали себя (через рекламу на Reddit )[1] как «Альтернатива Ethereum для разработчиков Javascript».
Вся их система на 100% состоит из javascript. Node.js для серверной части. Интерфейс. У них есть база данных — изначально SQLlite. Теперь постгрескл.
Эфириум
Смарт-контракты для Ethereum есть в Solidity или Serpent . Solidity очень похож на Javascript, но создан специально для смарт-контрактов. Чрезвычайно легко читать эти контракты и понимать, что они делают. Есть также несколько веских причин использовать собственный язык вместо Javascript (обсуждается ниже), когда речь идет о контрактах, которые перемещают валюту, сохраняют стоимость и требуют достижения консенсуса. Эта страница больше не поддерживается, но содержит несколько замечательных моментов о том, что такое Solidity, если вы хотите узнать больше.
Я не так много знаю о Serpent, но похоже, что у него те же цели и назначение, что и у Solidity, но он должен быть похож на Python (и, следовательно, отлично подходит для разработчиков Python). Это, наряду с рядом клиентов, также демонстрирует приверженность Ethereum к тому, чтобы быть привлекательным для широкого круга разработчиков, а не только для разработчиков Javascript.
Вышеупомянутое относится только к смарт-контрактам для Etheruem; как насчет более полного «Dapp»? Ну, это в значительной степени Javascript для пользовательского интерфейса Ethereum Dapp. Я рекомендую вам прочитать рецензию ConsenSys здесь, особенно часть II. По сути, у вас есть:
Truffle (встроены JS, Sass, ES6, JSX)
Отправляйтесь (это JS)
Метеор (web3.js + метеор (тоже JS))
и больше приходят.
Вывод
Таким образом, заявление Lisk о том, что разработчики Javascript не могут создавать Dapp для Ethereum, немного вводит в заблуждение. Они могут абсолютно точно использовать в первую очередь Javascript для Dapp, а затем Solidity (который так близок к Javascript) для смарт-контрактов. Сообщение в блоге, упомянутое выше, кратко говорит:
Изучение синтаксиса нового языка тривиально по сравнению с изучением того, как избежать миллионов способов, которыми вы можете выстрелить себе в ногу.
Разница в том, что Lisk полностью написан на Javascript (и node.js) насквозь, Ethereum имеет большое количество клиентов на разных языках[2], имеет два пользовательских языка для смарт-контрактов и по-прежнему позволяет использовать Javascript там, где он вам нужен. большинство (пользовательский интерфейс).
Чего некоторые люди не понимают, так это того, что Javascript, будучи чрезвычайно популярным, не делает его автоматически лучшим решением. Как я уже говорил выше, разница между Ethereum и Lisk здесь заключается в том, что Lisk на 100% состоит из Javascript, в то время как Ethereum имеет массу языков и позволяет разработчикам Dapp использовать Javascript для пользовательского интерфейса и Solidity для смарт-контрактов на блокчейне. При этом вот некоторые потенциальные недостатки Javascript в блокчейне:
Цифры Javascript... не самые большие и не самые надежные. Кроме того, когда мы имеем дело с криптовалютой, вы действительно хотите, чтобы ваши цифры были точными. В основном JS использует числа с плавающей запятой, что означает, что некоторые вещи аппроксимируются, а цифры в некоторых случаях теряются. Даже такие мелочи, как числа с плавающей запятой, могут нарушить консенсус. Вот еще чтение: будьте осторожны с большими числами и приближением с плавающей запятой . Итак, тот факт, что все в Lisk (включая сам Lisk) написан на Javascript, означает, что потенциально могут быть проблемы с большими числами (как с точки зрения больших чисел, так и с точки зрения больших проблем).
У Lisk есть «правила» , которым разработчики контрактов должны следовать, чтобы не нарушать консенсус. Сюда входят такие вещи, как «не использовать Math.random()». С Ethereum вам не нужно иметь правила. Код не скомпилируется, если вы попытаетесь сделать что-то не так. (К вашему сведению, вы не компилируете Javascript.) В Lisk, если вы используете Math.random(), он ломается.
Javascript использует слабую динамическую типизацию. Если вы не будете осторожны, вы можете передавать строки вместо чисел. Одно из основных различий между Solidity, Serpent и Javascript заключается в том, что Solidity и Serpent строго типизированы. Википедия о сильных и слабых объясняет это так:
Строго типизированный язык с большей вероятностью выдаст ошибку или откажется компилироваться, если аргумент, переданный функции, не соответствует ожидаемому типу. С другой стороны, очень слабо типизированный язык может давать непредсказуемые результаты или выполнять неявное преобразование типов.
Поскольку Ethereum выполняет контракты на блокчейне, а Lisk запускает Dapp на блокчейне (сайдчейн?), вы можете понять, почему слабо типизированный язык может привести к проблемам, особенно в отношении консенсуса. Гораздо лучше узнать о проблеме до того, как она превратится в неизменяемую вещь в цепочке, чем обнаружить, что все средства заблокированы, или вы разветвляете блокчейн, когда кто-то впервые пытается взаимодействовать с ним.
Дополнительные недостатки Lisk включают тот факт, что их «песочница» не может использоваться для запуска ненадежного кода, а их структура не обеспечивает защиты от недетерминированного поведения. Из сообщения в блоге выше:
Лиски могут быть разрешены с помощью тщательно настроенной среды JavaScript, которая удаляет числа с плавающей запятой, реализует программные прерывания, подсчет инструкций и более чистые API-интерфейсы для управления состоянием приложения. В конечном счете, создание компилятора JavaScript для виртуальной машины Ethereum может быть менее подвержено ошибкам, чем попытка исправить миллион недетерминированных утечек в JavaScript.
Как заметил пользователь Jehan, Solidity тоже не идеальна.
Существует небольшая поддержка сериализации и десериализации любого рода.
Он имеет чрезвычайно анемичную стандартную библиотеку (недавно была значительно обновлена)
Невозможно передать массив строк в контракт.
В Lisk Dapps на самом деле не хранятся в блокчейне , как байт-код смарт-контракта в Ethereum. Вместо этого у вас есть внешние ссылки на эти Dapp. Им нравится сравнивать свое Dapp с традиционной моделью «App Store» (вспомните Apple). Что, хотя и нравится некоторым пользователям, становится менее привлекательным, когда вы понимаете, что они буквально используют HTTP: ссылки на файлы .zip.
С Ethereum у вас есть код, хранящийся в блокчейне , что означает, что их можно проверить, и код нельзя изменить. Это своего рода цель децентрализованных приложений (IMO).
Lisk предпочитает использовать более широкое определение «децентрализованного», что означает, что буквально не хранится в центральном месте, в то время как разработчики и пользователи Ethereum предпочитают, чтобы децентрализованный означал что-то, что не может быть повреждено, может быть проверено, не может быть изменено, может достичь консенсуса и т. д. [3]
Один из наиболее распространенных аргументов любителей Ethereum против Lisk заключается в том, что Lisk (1) не имеет за собой команды разработчиков и (2) возникла как неудачная альтернативная монета, Crypti, которая была заброшена разработчиками (3) те разработчики, которые отказались от Crypti, являются разработчиками Lisk, так что (4) это просто ребрендинг?
Основное различие, которое я вижу между Ethereum и Lisk здесь, заключается в том, что Lisk — это два парня, которые провели ребрендинг предыдущей монеты, у которой была предпродажа и ничего не было доставлено, в то время как у Ethereum есть Виталик Бутерин, большая команда известных, вовлеченных в сообщество, безумно талантливых людей. разработчики и большое сообщество разработчиков, работающих над основным кодом (все с открытым исходным кодом), Dapps и сторонними кошельками и т. д.
Еще одно ключевое отличие состоит в том, что у Ethereum есть Ethereum Foundation, некоммерческая швейцарская организация, а у Lisk есть... неизвестный фонд/компания, связанная с ним.
[1] Вот скриншот, потому что эта ссылка прикольная.
[2] Ethereum поражает количеством языков/клиентов. На данный момент у нас есть: Geth (Go), WebThree (C++), PyEthereum (Python), Parity (Rust), EthereumJ (Java), Ethereum-Ruby (Ruby), NEthereum (.net). Я вижу в этом большое преимущество Ethereum, и, как отметила команда Ethereum, тот факт, что существует так много клиентов на стольких языках, имеет неоценимое значение для тестирования, обнаружения ошибок и обеспечения консенсуса.
@tayvano: К сожалению, я не могу комментировать напрямую. Для этого мне нужно "50 репутации". Поэтому я напишу это как новый ответ.
Я не так много знаю о Serpent, но похоже, что у него те же цели и назначение, что и у Solidity, но он должен быть похож на Python (и, следовательно, отлично подходит для разработчиков Python). Это, наряду с рядом клиентов, также демонстрирует приверженность Ethereum к тому, чтобы быть привлекательным для широкого круга разработчиков, а не только для разработчиков Javascript.
Диапазон клиентов в Ethereum на Go, C++, Python, JavaScript, Java и других языках — катастрофа поддержки. Прямо сейчас это может работать нормально, но как только Ethereum наберет критическую массу, появится 1 (или, может быть, 2) клиента, которыми будут пользоваться 99% пользователей. В противном случае это просто невыполнимо.
Вы также говорите, что Ethereum пытается привлечь внимание широкого круга разработчиков. Lisk имеет тенденцию сосредотачиваться на группе JavaScript, просто факт, что это уже огромная толпа. Lisk устраняет трения , очень сложно найти разработчиков для платформы. Если им сейчас нужно выучить новый язык (помимо всей концепции блокчейна), привлечь их будет еще сложнее. Lisk — это все о том, чтобы оставаться бережливым, эффективным и сосредоточенным.
Кстати. JS чрезвычайно мощен: asmjs.org, pyjs.org и т. д.
Вышеупомянутое относится только к смарт-контрактам для Etheruem; как насчет более полного «Dapp»?
Вот разница между Lisk и Ethereum. Ethereum выполняет смарт-контракты, которые все сохраняются в одной цепочке блоков. Если вы хотите разработать децентрализованное приложение в Ethereum, вам необходимо соединить функциональные возможности нескольких смарт-контрактов.
В Lisk вы получаете полный пакет. Вы не разрабатываете отдельные смарт-контракты. Вы создаете целое приложение, которое работает на собственной цепочке блоков. Вы как будто разрабатываете новую криптовалютную платформу с расширенным набором функций, сама платформа уже готова и предоставляется нашим Lisk SDK. Как разработчику вам просто нужно реализовать необходимые новые функции поверх уже существующей платформы.
Таким образом, заявление Lisk о том, что разработчики Javascript не могут создавать Dapp для Ethereum, немного вводит в заблуждение. Они могут абсолютно точно использовать в первую очередь Javascript для Dapp, а затем Solidity (который так близок к Javascript) для смарт-контрактов.
Мы никогда не говорили, что разработчики JavaScript не могут создавать децентрализованные приложения для Ethereum. Конечно, могут, но сначала им нужно выучить новый язык. Это все равно что сказать, что сантехник не может красить стены.
В Ethereum они могут использовать JavaScript для интерфейса децентрализованного приложения и Solidity для серверной части децентрализованного приложения. Не то чтобы они использовали JavaScript «для [полного] децентрализованного приложения», как вы сказали. Нет, только для передней части.
Разница в том, что Lisk полностью написан на Javascript (и node.js) насквозь, Ethereum имеет большое количество клиентов на разных языках[2], имеет два пользовательских языка для смарт-контрактов и по-прежнему позволяет использовать Javascript там, где он вам нужен. большинство (пользовательский интерфейс).
Да, мы склонны концентрироваться на одной технологии. Фокус является ключевым.
Ваше заявление о том, что Ethereum «позволяет использовать JavaScript там, где он вам нужен больше всего (пользовательский интерфейс)», на самом деле относится только к Ethereum. JavaScript принят во всем мире для многих различных задач во внешнем и внутреннем интерфейсе (например, NodeJS). Не только для «UI». Вы делаете JavaScript меньше, только чтобы получить больше аргументов в пользу Solidity.
Цифры Javascript... не самые большие и не самые надежные. Особенно, когда мы имеем дело с криптовалютой, вы действительно хотите, чтобы ваши цифры были точными. В основном JS использует числа с плавающей запятой, что означает, что некоторые вещи аппроксимируются, а цифры в некоторых случаях теряются.
Мы используем только целые числа в Lisk. Для больших чисел мы используем bignumber.js. Дело не в выбранном вами языке, а в ваших навыках программирования. Если вы знаете, что делаете, с JavaScript все в порядке. Впрочем, да, это слабость. Но слабость, с которой можно справиться.
Javascript использует слабую динамическую типизацию. Если вы не будете осторожны, вы можете передавать строки вместо чисел.
Честно говоря, если вы строите серьезный проект, вы должны, по крайней мере, сделать это правильно. В противном случае каждый проект JavaScript потерпит неудачу в соответствии с вашим аргументом.
У Lisk есть «правила», которым разработчики контрактов должны следовать, чтобы не нарушать консенсус.
Ага. Кажется, что Ethereum имеет эти «правила», встроенные непосредственно в их компилятор, в Lisk разработчики просто должны им следовать. Самая большая разница здесь в том, что если они совершат ошибку и консенсус будет нарушен, то децентрализованному приложению потребуется хардфорк. Но с самим Lisk все в порядке, потому что децентрализованное приложение работает только в сайдчейне.
Это огромное преимущество в плане безопасности. Если децентрализованное приложение выходит из строя, сеть Lisk даже не дает сбоев. Однако, если один смарт-контракт терпит неудачу в Ethereum, это может означать, что игра для Ethereum окончена.
Недостатки твердости
Другим недостатком может быть то, что это очень молодой язык и, следовательно, непроверенный. Также очень мало доступной документации, и еще меньше разработчиков знают этот язык.
На блокчейне
Вы сейчас смешиваете разные вещи. Вы загружаете биткойн-клиент также по HTTP-ссылке. Однако он «не может быть поврежден, может быть проверен, не может быть изменен, может быть достигнут консенсус». Это означает, что все упомянутые вами важные свойства применимы и к Lisk. Если вы измените код децентрализованного приложения, ваша нода окажется в форке. Так же, как если бы вы изменили биткойн-код.
Ссылка HTTP — это единственный способ распространения исходного кода децентрализованного приложения. Позже мы интегрируем методы децентрализованного хранения (например, IPFS), чтобы можно было децентрализовать и сам дистрибутив.
Однако модель распространения не определяет, является ли приложение централизованным или децентрализованным. Или вы говорите, что каждая криптовалюта на рынке централизована? Потому что вы загружаете клиентов из централизованного места? Если да, то как децентрализовать децентрализованные приложения Ethereum, если сама сеть централизована? ;)
Здесь ваша аргументация неверна. Еще одним важным фактом является то, что этот метод позволяет масштабировать Lisk намного проще, чем Ethereum. Помимо огромных преимуществ, наши сайдчейны уже приносят пользу.
Я мало что знаю о Crypti, но у них была предпродажа, и они получили приличную сумму денег (не менее 200 тысяч долларов США), но я не могу найти точные цифры, потому что все было стерто. Из Крипти ничего не вышло. Буквально. Так... это страшно. Отсутствие прозрачности тоже пугает.
Мы больше не связаны с Crypti. Однако говорить о том, что все стерто и что прозрачности нет, — огромная ложь. На Bitcointalk более 600 страниц ( https://bitcointalk.org/index.php?topic=654463 ) и десятки сообщений в блогах ( https://blog.crypti.me ), которые содержат ВСЮ информацию.
Кроме того, если вы говорите, что «из Crypti ничего не вышло», то вы совершенно неправы. Crypti разработала работающую платформу децентрализованных приложений, и огромный успех Lisk доказывает это. Единственное, что не работало в Crypti, — это маркетинг. Это означает, что никто не знает о Crypti. В Crypti также не хватало руководства.
Итак, я думаю, основное различие между Ethereum и Lisk, на которое я хочу указать, заключается в том, что Lisk — это два парня, которые переименовали предыдущую монету, у которой была предпродажа и ничего не было доставлено, в то время как у Ethereum есть Виталик Бутерин, большая команда известных, комьюнити- вовлеченные, безумно талантливые разработчики и большое сообщество разработчиков, создающих Dapp и сторонние кошельки, аппаратные кошельки и всевозможные удивительные вещи. Я имею в виду, посмотрите только на Augur, Slock.it и ConsenSys. Это безумие!
Да, я рад, что эти два парня из Google так и не основали свою компанию, потому что тогда было так много отличных поисковых систем с сотнями сотрудников. :)
Не поймите меня неправильно, мне нравится Ethereum и вся команда/движение, стоящее за ним. Я большой сторонник. Но вы просто отказываетесь от инноваций в данный момент. Вы сравниваете платформу двухлетней давности (Ethereum) с 18 млн финансирования, с еще даже не запущенной платформой (Lisk), у которой еще нет доступа к финансированию. Это глупо.
Еще одно ключевое отличие состоит в том, что у Ethereum есть Ethereum Foundation, некоммерческая швейцарская организация, а у Lisk есть... неизвестный фонд/компания, связанная с ним.
Все в Lisk знают, что мы находимся в процессе создания юридического лица в Германии, скорее всего, в виде gGmbH. Это также некоммерческая организационная структура.
И последнее замечание: Lisk действительно любит заявлять, что у них есть партнерские отношения с громкими именами. Сначала это был ShapeShift. Теперь это Майкрософт. Они любят использовать это партнерское слово. На самом деле они просто использовали кнопку Shifty, а не партнерство.
У нас было технологическое партнерство с ShapeShift. В то время это было большим недоразумением. Они уже исправили эту ошибку.
В целом, я хотел бы сказать, что ваши пункты довольно слабы. Вы не указали на самые большие недостатки Lisk. На мой взгляд, это безопасность сайдчейна. Это означает, что у небольших децентрализованных приложений, вероятно, не будет возможности в долгосрочной перспективе привлечь достаточное количество узлов для их защиты.
Для этого я подозреваю, что будут специальные децентрализованные приложения, которые будут запускать меньшие децентрализованные приложения по принципу SaaS. Пока мы не внедрили рынок сайдчейн-форжинга, поиск сайдчейн-форжеров также был довольно сложной задачей. Однако все это только начальные проблемы. Все решаемо. В конце концов, Lisk — это просто программа, которая активно развивается.
Важно отметить, что Lisk только запускается, а мы уже вносим большие изменения. На данный момент еще слишком рано оценивать Lisk и команду (нас), стоящую за ним. Вы должны просто подождать год, прежде чем сделать окончательный вывод. Все аргументы прямо сейчас выглядят так, будто ты боишься. Лично я думаю, что места для Ethereum и Lisk более чем достаточно. В конце концов, мы решаем «проблемы» очень по-разному и занимаем разные ниши.
Я надеюсь, что Ethereum и Lisk смогут работать вместе в будущем, чтобы решить важные проблемы в индустрии децентрализованных приложений и блокчейнов. Повторяю, мы вместе в этой "игре".
осевой