<div class="pull-right">

![](https://steemitimages.com/DQmeb1bXje2aQcnBhUwuV4ZY3xS1uNio3TedqabCLqFvMTU/image.png)
</div>

This week block.one’s blockchain c++ development team has picked up 4 new members and has been interviewing a few more. The new recruits have already begun making contributions to the code.
 
## Removing Registered Message Schemas
 
With the move to WebAssembly (WASM) we have had to re-evaluate some of our earlier design decisions based on the assumption of using Wren.  Because WASM is language independent, every application would have to provide different WASM for parsing the messages passed to the application. This means the ABI (application binary interface) is technically defined by the WASM parsing and not our prior builtin registered message types and formats. 
 
Since the blockchain is unable to enforce the message schemas and every contract would have to independently parse and validate the incoming binary data, we opted to remove the blockchain defined message schemas.  This gives more power to application developers.
 
## Changing Account Name Structure
One of the bigger [changes to the code](https://github.com/EOSIO/eos/issues/56)  this week was changing account names from 256 bit strings to 60 bit integers that convert to human-readable names via base32 encoding.  This limits the account names to 12 lowercase letters and a few numbers. The average Twitter account is only 12 characters long.
 
This change was made primarily out of bandwidth, memory, and performance considerations. From an applications logic perspective an account name is simply a unique identifier and they are used everywhere. The old ABI would serialize these account names as length-prefixed strings and require a computationally intensive unpacking process.  
 
By moving to a fixed-width integer representation for accounts we got performance, but the developer experience was less friendly. To resolve this we simply print the integers as base32 and this gives human-readable names.
 
Longer names can still be supported by registering them with a name service contract. 

A typical transfer message is 75% smaller after this change, which makes a big difference when you are processing 10's of thousands of them per second.
 
## Filtering Floating point from WASM
We updated the WASM processing to detect and reject code that uses floating point operations which can generate non-deterministic behavior. 
 
## Sandboxing WASM Runtime
We made significant progress toward injecting checkpoints into WASM to allow us to check the runtime and abort if too much time has passed.  This is a critical component of running untrusted code.
 
## New C++ Simplecoin  (80,000 TPS)
 
In one of my [prior updates I showed a proof-of-concept currency smart contract written in C](https://steemit.com/eos/@dantheman/web-assembly-on-eos-50-000-transfers-per-second) and achieving 50K transactions per second. I mentioned that I thought we could clean up the syntax and today I am happy to show a new implementation of the simplecoin in C++ that gets compiled to WASM and then executed.   Using a tight loop of generating and pushing transactions to the blockchain we achieved 80K TPS transferring funds from one account to another in a single thread.  
 
***Real world performance may be higher or lower based upon the evolving architecture, it is still too early to tell.  All measurements were made on a 4Ghz Intel Core i7 in a 2014 iMac.***
 
```
struct Transfer {
  uint64_t    from;
  uint64_t    to;
  uint64_t    amount;
  char        memo[];
};
 
static_assert( sizeof(Transfer) == 3*sizeof(uint64_t), "unexpected padding" );
 
struct Balance {  uint64_t    balance; };
 
void on_init() {
  static Balance initial = { 1000*1000 };
  static AccountName simplecoin;
  simplecoin = name_to_int64( "simplecoin" );
 
  store( simplecoin, initial ); 
}
 
void apply_simplecoin_transfer() {
   static Transfer message;
   static Balance from_balance;
   static Balance to_balance;
   to_balance.balance = 0;
 
   readMessage( message  );
   load( message.from, from_balance );
   load( message.to, to_balance );
 
   assert( from_balance.balance >= message.amount, "insufficient funds" );
   
   from_balance.balance -= message.amount;
   to_balance.balance   += message.amount;
   
   if( from_balance.balance )
      store( message.from, from_balance );
   else
      remove( message.from );
 
   store( message.to, to_balance );
}
```
 
Not only is the code cleaner and easier to read, the generated WASM code is much smaller too.  Most of this time and space savings is made possible by changing the account name and ABI for this contract.  In this case the ABI uses a zero-parse copy from the database to the c++ struct and all account names are fixed length.
 
You can experiment with this code on WasmFiddle with this [shared link](https://wasdk.github.io/WasmFiddle/?11oykv).
 
## Conclusion
 
The EOS development team is growing and the technology is progressing with all signs pointing toward a very high-performance platform even running in a single thread.  Stay tuned for more updates!