axic

Block

• blockHash -> getBlockHash
• coinbase -> getCoinbase
• difficulty -> getDifficulty
• gasLimit -> getBlockGasLimit
• number -> getBlockNumber
• timestamp -> getBlockTimestamp

Tx

• gasPrice -> getTxGasPrice

axic

;; Contract: EWASMTest
(module
	(import $calldatacopy "ethereum" "calldatacopy" (param i32 i32 i32))
	(import $sstore "ethereum" "sstore" (param i32 i32))
	(import $return "ethereum" "return" (param i32))
	(memory 1 1)
	(export "memory" memory)
	(export "main" $main)
	(func $main
		(call_import $calldatacopy (i32.const 0) (i32.const 0) (i32.const 4))

axic

LLVM on the high level could be separated into:

• 1. Core (operations which work on the LLVM IR AST)
• 2. Optimisers
• 3. Backends/targets - these generate the instructions for a given CPU (i.e. x86, ARM, WebAssembly, etc.)

There are many projects creating frontends for LLVM, which are actual compilers outputting LLVM IR.

Some of these include:

• clang (C and C++)
• llgo (Go)

axic

//
// Needs web3.js from https://github.com/axic/web3.js/tree/swarm
//

var Web3 = require('web3')
var url = require('url')

var web3 = new Web3(new Web3.providers.HttpProvider('http://localhost:8545'))
try {
  web3.eth.defaultAccount = web3.eth.coinbase

axic

Ethereum support in Trezor is in early development. The following steps can help you to get started.

First of all have a read at the protocol discussion thread.

To summarize the key decisions:

• Transaction data is taken as raw binary, all fields of the transaction separately (in order they appear).
• Every field is optional and it defaults to 0 if something is not supplied.
• Trezor will internally recreate the RLP of those fields, hash it and create a signature.
• The above is in a streaming manner and thus no RLP data is kept nor returned to the client.
• Only the signature fields (v, r, s) are returned. The callee then needs to recreate the RLP structure and include the signature fields.

axic

//
// Big number library in Solidity for the purpose of implementing modexp.
//
// Should have a similar API to https://github.com/ethereum/EIPs/issues/101
//
// Internally bignumbers are represented as an uint array of 128 bit values.
//
// NOTE: it assumes usage with "small" (<256bit) exponents (such as in RSA)
//

axic

Ethereum Object Notation (ETON)

A simple ABI structure to replace JSON's object when passed between contracts. It is especially useful when interacting with outside oracles, where a JSON would be converted into this notation.

A JSON supports the following object types:

• number (double precision floating point)
• string (double quoted unicode string)
• boolean (true or false)
• array (ordered sequence)
• null

axic

There's a long discussion about using BIP32 (the Bitcoin HD wallet KDF) and BIP44 (the KDF path standard) for Ethereum.

It was raised that perhaps a different scheme could be useful.

How Bitcoin HD wallets work?

1. A mnemonic (i.e. a list of memorable words) is generated (see BIP39)

2. This mnemonic is converted to a seed using PBKDF2 (see BIP39)

axic

//
// In Solidity, a mapping is like a hashmap and works with `string` like this:
//   mapping (string => uint) a; 
//
// However it doesn't support accessors where string is a key:
//   mapping (string => uint) public a;
//
// "Internal compiler error: Accessors for mapping with dynamically-sized keys not yet implemented."
//
// An accessor returns uint when called as `a(string)`.

axic

//
// The new assembly support in Solidity makes writing helpers easy.
// Many have complained how complex it is to use `ecrecover`, especially in conjunction
// with the `eth_sign` RPC call. Here is a helper, which makes that a matter of a single call.
//
// Sample input parameters:
// (with v=0)
// "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad",
// "0xaca7da997ad177f040240cdccf6905b71ab16b74434388c3a72f34fd25d6439346b2bac274ff29b48b3ea6e2d04c1336eaceafda3c53ab483fc3ff12fac3ebf200",
// "0x0e5cb767cce09a7f3ca594df118aa519be5e2b5a"