EOS - Developer Log, Stardate 201707.7

in #eos7 years ago

This week we made great strides toward refining the architecture of EOS and defining the developer API. In particular we have identified a programming model that should enable parallelism while maximizing ease of use and clarity of the code.

Updated Example Contracts

Those who have been following github may have noticed that we have started to integrate a number of example contracts to test our architecture and ensure we can cover the desired use cases.

This is what a simple currency contract looks like today:

/**
 *  Transfer requires that the sender and receiver be the first two
 *  accounts notified and that the sender has provided authorization.
 */
struct Transfer {
  AccountName from;
  AccountName to;
  uint64_t    amount = 0;
  char        memo[]; /// extra bytes are treated as a memo and ignored by logic
};

struct CurrencyAccount {
   CurrencyAccount( uint64_t b = 0 ):balance(b){}

   uint64_t balance = 0;

   /** used as a hint to Db::store to tell it which table name within the current 
    *  scope to use.  Data is stored in tables under a structure like
    *
    *  scope/code/table/key->value
    *
    *  In this case the "singleton" table is designed for constant named keys that
    *  refer to a unique object type. User account balances are stored here:
    *  
    *  username/currency/singleton/account -> CurrencyAccount
    */ 
   static Name tableId() { return NAME("singleton"); }
};


void apply_currency_transfer() {
   const auto& transfer  = currentMessage<Transfer>();

   /** will call apply_currency_transfer() method in code defined by transfer.to and transfer.from */
   requireNotice( transfer.to, transfer.from );
   requireAuth( transfer.from );

   static CurrencyAccount from_account;
   static CurrencyAccount to_account;

   Db::get( transfer.from, NAME("account"), from_account );
   Db::get( transfer.to, NAME("account"), to_account );

   assert( from_account.balance >= transfer.amount, "insufficient funds" );
   from_account.balance -= transfer.amount;
   to_account.balance   += transfer.amount;

   if( from_account.balance == 0 )
      Db::remove<CurrencyAccount>( transfer.from, NAME("account") );
   else
      Db::store( transfer.from, NAME("account"), from_account ); 

   Db::store( transfer.to, NAME("account"), to_account ); 
}

There are several notable aspects about this currency contract:

  1. it looks like normal sequential code
  2. but it can transfer among two pairs of users in parallel

What does this mean? It means that while Alice is transferring to Bob, Sam can be transferring to Jill. The performance of this currency contract is no longer limited by the single threaded performance constraints of prior currency contracts.

Start of Exchange Contract

We have also implemented a simple exchange contract that accepts deposits and withdraws from two different currency contracts:

struct Account {
   uint64_t   a = 0;
   uint64_t   b = 0;
   int        open_orders = 0;

   bool isEmpty()const { return !(a|b|open_orders); }
   /**
    *  Balance records for all exchange users are stored here
    *  exchange/exchange/balance/username -> Balance
    */
   static Name tableId() { return Name("balance"); }
};



/**
 *  This method is called after the "transfer" action of code
 *  "currencya" is called and "exchange" is listed in the notifiers.
 */
void apply_currencya_transfer() {
   const auto& transfer  = currentMessage<Transfer>();

   if( transfer.to == "exchange" ) {
      static Balance to_balance;
      Db::get( transfer.from, to_balance );
      to_balance.a += transfer.amount;
      Db::store( transfer.from, to_balance );
   } else if( transfer.from == "exchange" ) {
      requireAuth( transfer.to ); /// require the reciever of funds (account owner) to authorize this transfer

      static Balance to_balance;
      auto balance = Db::get( transfer.to, to_balance );
      assert( balance.a >= transfer.amount, "insufficient funds to withdraw" );
      balance.a -= transfer.amount;

      if( balance.isEmpty() )
         Db::remove<Balance>( transfer.to );
      else
         Db::store( transfer.to, to_balance );
   } else {
      assert( false, "notified on transfer that is not relevant to this exchange" );
   }
}

/**
 *  This method is called after the "transfer" action of code
 *  "currencya" is called and "exchange" is listed in the notifiers.
 */
void apply_currencyb_transfer() {
   const auto& transfer  = currentMessage<Transfer>();

   if( transfer.to == "exchange" ) {
      static Balance to_balance;
      Db::get( transfer.from, to_balance );
      to_balance.b += transfer.amount;
      Db::store( transfer.from, to_balance );
   } else if( transfer.from == "exchange" ) {
      requireAuth( transfer.to ); /// require the reciever of funds (account owner) to authorize this transfer

      static Balance to_balance;
      auto balance = Db::get( transfer.to, to_balance );
      assert( balance.b >= transfer.amount, "insufficient funds to withdraw" );
      balance.b -= transfer.amount;

      if( balance.isEmpty() )
         Db::remove<Balance>( transfer.to );
      else
         Db::store( transfer.to, to_balance );
   } else {
      assert( false, "notified on transfer that is not relevant to this exchange" );
   }
}

What is interesting about this implementation is that deposits and withdraws occur without any asynchronous callbacks or other complex pending states. Rather than the user asking the exchange to tell the currency contract to withdraw funds, the exchange gives everyone permission to transfer from the exchange with the caveat that the exchange's handler for transfers is called on both deposits and withdraws. If a user attempts to withdraw more than their balance with the exchange contract the handler will reject the transfer attempt.

We have not quite yet implemented working tests of the exchange contract deposit and withdraw, but that is on the agenda for next week. We will also be implementing a basic social media application to prove that we have all the existing use cases covered.

Synchronous Calls

One of the biggest developments this week as an architecture that allows synchronous calls among tightly coupled applications while still retaining most of the benefits of parallelism. A future blog post will go into greater detail on our memory and parallel execution structure.

Cost of Storage

Some people have expressed concerns that if tokens are worth $30 billion dollars and there is only 1 TB of storage capacity that the cost of storage will be too high. I have prepared an article that explains how we address this and keep the cost of storage mostly independent from token price.

EOS.IO development is making great strides!

Sort:  

You @Dan are one of the vital few who are pushing human progress forward. Thank you. Most of the rest of us here are just hairless monkeys. (Myself included). Keep on building that market for liberty.

Most people do not understand why Dan is doing what he is doing - Dan isn't making money or neat tech, he is making a better future for all of us. Sounds a bit grandiose but it is simply the truth. One day EOS and other blockchain tech may enable governance without the coercion, violence, corruption, disparity and waste we all seem to accept as normal today. The big picture for these blockchains is very, very big...

That's the idea, let's see how things will turn out in future.

I could not have said it better myself. Thank you

I second this notion, Kudos to @dan!

Thank you Dan for all your devotion on the EOS project. It's exciting to see big names beginning to back EOS.

EOS is still fighting for a good place in the market, anyway the idea and technology behind it is great. But Marketing and usage is the main key to gain value in the market and EOS still Lacks that.
so my message: Do not focus only on the development of the coin itself in terms of technology, but focus as well on gaining a lot of Merchants in order to rise the value. Furthermore try to include EOS in other famous exchanges.
Cheers

I feel like once the tech is proven worthy of use it will be adopted with ease which makes marketing easier as well

True Flip {ICO} - Already running a transparent blockchain lottery! Bomb! Bonus 20%! Hurry! :)
The platform is already working and making a profit :)
https://steemit.com/ico/@happycoin/true-flip-ico-already-running-a-transparent-blockchain-lottery-bomb-bonus-20-hurry

I wonder why an EOS-based exchange contract need deposit or withdrawals at all. It should like BitShares, all tokens are already in an exchange, users can place orders directly.

Because exchange contract runs in parallel. A user could construct a transaction to transfer and then create order atomicly, but unless the order is filled immediately they will have to execute a withdrawal later.

I think , if they're fully in parallel, then the two things (deposit then create order) are hard if not impossible to be processed atomically if there're two operations in one transaction. The deposit itself has to be a message from a user to the token contract, after it's done, communication should be made between the token contract and the exchange contract. Either the exchange contract explicitly ask the token contract to make sure the deposit is done, which requires a lock and perhaps a delay, or the token contract need to send a message to the exchange contract, which will need a delay as well, and contains the user's info when the user requested the deposit, but in this case, the user can directly request an "order creation" in the same way, so doesn't need a single "deposit" feature. When an order is filled, the exchange contract can immediately talk to another token contract directly to deposit the funds back to the user, so don't need the user to request a withdrawal. I do agree that simple deposit and withdrawal features are acceptable, which will help keep state in one contract only and simplify the logic, but perhaps it's not necessary. Ideally, the user should be able to attach a script with a deposit (which is a message to the token contract), for example, do nothing, or to place an order immediately; also in the script, the user can indicate when the order is filled/expired/cancelled, return the funds to the user or place another order, etc, etc.

//UPDATE: above comment was written before carefully read the blog post and the code, so it may be wrong. I will update with more info later.

//UPDATE2: so messages will be validated by all registered notifiers (contracts). If failed to pass a validation in one notifier then all changes done in other contracts will need to be rolled back. Interesting. How to do them in parallel?

I totally agree, bitshares is the way to go and the future

Keep up the great work, I know all of that money can be distracting and so can the pressure of trying to create something great.

Hi, guys, Follow me and Upvote my posts in my blog and i will do the same thing!!!
DQmTiCwPX5Eh6J9TrHZ9Aki1E8u7jM6gc2LqvycQ91JFrjQ.gifDQmSU1hzsgYXpLoTgCd69jJHNJaNfZZj15c4dFDAwSLLxwM_1680x8400.png

Nice to read about the progress made in steemit. Keep up the work.

Let's get this show on the Road Have me some 100 EOS can't wait for the tech! Thanks, Dan!

Oh @dan! EOS is great!

Hi, guys, Follow me and Upvote my posts in my blog and i will do the same thing!!!
DQmTiCwPX5Eh6J9TrHZ9Aki1E8u7jM6gc2LqvycQ91JFrjQ.gifDQmSU1hzsgYXpLoTgCd69jJHNJaNfZZj15c4dFDAwSLLxwM_1680x8400.png

This is great work, specially "One of the biggest developments this week as an architecture that allows synchronous calls among tightly coupled applications while still retaining most of the benefits of parallelism." I read your post about "Storage" you explained the things in great way, good work dan

You know... this post is a great example of how you guys SHOULD have been using SteemIt when you launched. SteemIt is a PERFECT platform for Press Releases and documenting changes and news about something... anything. In my case, I use Steem as a Publishing System. The LEAST you guys could have done at SteemIt was to post REGULARLY about the Platform, the day to day operations, and important updates.

Glad to see you've FINALLY learned this for EOS. Maybe @ned will get a clue after this post and go back to some regular posting about the Company he's in charge of...

Also, please understand that I'm just being FRANK and not looking to insult YOU or anyone related to SteemIt Inc. I just think it's hysterically obvious and felt the need to point it out.

Good luck with EOS and SteemON my man...

Imgur

Im a EOS investor. Hold because it will go to 3digits....

Domi

Are you reffering to being in the USA?

Domi

Were in a tough situation because USA Can Not participate. Also, they are offloading shares every so offten so get used to the price rising/dropping throughout this process.

What do you think will happen to this coin?

Domi

Great job coding. im not too familiar on how it hows, but i did I put together a quick video feat. @crypt0. Hope you guys enjoy it!
image
https://steemit.com/crypto-news/@vizualsamuri/why-this-crypto-ep-2-omar-bham-aka-crypt0-ethereum-201777t13421939z