Создание гипотетического денежного приложения на EOS.

Сегодня мы рады поделиться с Вами первым представлением о том, как работает EOS, и как разработчики создают на нем приложения.

Высокоуровневое описание

EOS структурирован как группа людей и/или сценариев (ботов), которые обмениваются между собой сообщениями. Это можно представить как систему электронной почты, где у каждого бота или пользователя есть свой аккаунт.

Как и у сообщений электронной почты, у этих сообщений есть отправитель, получатель и несколько аккаунтов, скопированных в сообщении. Так же, как и в электронной почте, доставка сообщений не гарантируется только потому, что они были отправлены. Доставка сообщения подразумевает, что получатель принял сообщение и обработал его в соответствии с кодом получателя.

В отличие от электронной почты, получатель и аккаунты, указанные в сообщении, могут отклонить сообщение, в этом случае сообщение им доставлено не будет.

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

Публикуется код, а не бинарники

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

Структура приложения

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

Каждый аккаунт может определять любое количество типов, т.е. структур. Эти структуры определяют двоичное последовательное размещение сообщений и позволяют каждому конвертировать двоичные представления в привычный для человека вид JSON. Это позволяет блокчейну оставаться прозрачным для всех, при этом обладая эффективным исполняемым бинарным кодом

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

Пример денежного приложения

Один из простейших видов приложений - это деньги. В данном примере мы рассмотрим, как денежные приложения могут быть структурированы в EOS.

Дисклеймер

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

Базовый денежный контракт

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

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

<code>  to      AccountName
  from    AccountName
  amount  UInt64

struct Init

table Balance
  owner   AccountName
  balance UInt64

on Init action
   precondition:
     eos.requireAuthority( eos.thisAccount() )
     eos.require( !Balance.find( eos.thisAccount() ) ) /// only call once

   apply:
     self         = Balance.new()
     self.owner   = eos.thisAccount()
     self.balance = 100000  /// maximum currency supply
     Balance.save(self)
on Transfer action
   validate:
     // static validation, verifies action is internally consistent
     // no access to database tables
     eos.require( action.amount > 0 ) 
     eos.require( action.to != action.from ) 
     eos.requireNotify( action.to ) 

   precondition:
     // identify possible precondition check that can 
     // be executed with readonly access
     eos.require( Balance[action.from].balance >= action.amount )
     eos.requireAuthority( action.from )

   apply:
     // assuming all prior steps pass, perform the state transition
     // that updates balances and/or creates a new account for receiver
     var from = Balance[message.from]
     var to   = Balance.find( action.to )

     if( !to ) {
        to         = Balance.new()
        to.owner   = action.to
     }

     from.balance = from.balance - action.amount
     to.balance   = to.balance   + action.amount

    Balance.save(to)

    if( from.balance > 0 )
        Balance.save(from)
    else if( from != eos.thisAccount() ) 
        Balance.delete(from)
</code>

На заметку

Обработчики событий разделены на три секции: проверка, предварительное условие и исполнение. Эти секции разделяют обработку на совершенно разные этапы, что позволяет произвести оптимизацию производительности и запустить их параллельно. Проверка и предварительные условия предназначены только для чтения, что означает, что они могут обрабатываться параллельно.

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

follow me

Переведено @finch

Оригинал поста: ЗДЕСЬ

иСТОЧНИК https://steemit.com/ru/@blockchained/sozdanie-gipo...