axic

// ReedemableNFT, where a curator can issue a redeemable cheque for minting a given token.
//
// The message to be signed is an EIP-712 compatible structured data:
//   struct RedeemableNFT {
//       address recipient;
//       uint256 tokenId;
//   }
//
// This message can then signed by the curator and given to the user who submits it.
// The validity of the signature is checked according to EIP-1271 if the signer is a contract,

axic

"Crossover" EE

The "crossover" execution environment aka Eth1-esque abstraction over Phase2

The current proposals for Eth 2 Phase 2 revolve around a purely stateless architecture, where the only stored information is the state root of each "execution environment" on a shard. This is in stark contrast to the stateful mode of operation on Eth1.

This model expects higher level abstractions to be built atop this simple system. Here follows one proposal to achieve a familiar environment as a higher level abstraction.

axic

/*
 * QIMalloc - Quick, incremental malloc.
 *
 * This is a dummy malloc implementation, without the option to free memory space.
 */
 
static int __malloc_ptr = 0;
static int __malloc_end = 0;

void *malloc(size_t size) {

axic

// CREATE2 proxy for constantinople/petersburg which allows easy deploying of
// contracts using the same address on multiple chains.
//
// Idea by @Arachnid. Some code by @axic.

pragma solidity ^0.5.0;

contract Create2Proxy {
  function() external payable {
    assembly {

axic

Handshake - Keys and Addresses

DISCLAIMER: There is no warranty for any of the below be correct, up to date, or valid in any form. This is not a specification, only the braindump of some code digging. In fact it is very likely all of this is incorrect and useless. DO NOT PUT TOKENS INTO ADDRESSES GENERATED USING THE INFORMATION BELOW.

From their website:

Decentralized certificate authority and naming

An experimental peer-to-peer root DNS.

Handshake aims to "airdrop" a large quantity of the tokens to developers (backed by Github and Freenode profiles) or well known people (backed by PGP WoT).

axic

ewasm “WRC20” token contract coding challenge

This document describes a simple contract in pseudocode and gives a couple of test cases for it.

The challenge is designed to be fairly easy to implement in a language of choice, compiled to wasm and interacted with. It is loosely based on the ERC20 token standard, named "WRC20", where the W stands for WebAssembly.

External interface

The contract has two features:

axic

eWASM and Backwards Compatibility
=================================

High Level
----------

Pros:
-   ease transition: legacy EVM compatible with eWASM

Cons:

axic

/*
 * WARNING: Proof of concept. Do not use in production. No warranty.
 *
 * Safe transfer workaround for not fully ERC20 compatible tokens.
 * Well, ERC20 had a lot of revision, who I am to say something is not compatible :)
 *
 * Read the following for more explanation: https://github.com/ethereum/solidity/issues/4116
 *
 * In short:
 *   The final ERC20 standard (IIRC) requires the transfer function to return a boolean. Some tokens do not return anything

axic

/*
 * This is a helper to check if a Solidity contract function is running as part of a constructor.
 */
library ContractHelper {
    function runningInConstructor() internal view returns (bool ret) {
        assembly {
            ret := iszero(iszero(extcodesize(address)))
        }
    }
}

axic

;; "Hello World" in Brainf* compiled to eWASM using https://github.com/axic/bf-compiler-webassembly/tree/ewasm

(module
  
  (func $callDataCopy (import "ethereum" "callDataCopy") (param i32 i32 i32))
  (func $return (import "ethereum" "return") (param i32 i32))
  (global $writeptr (mut i32) (i32.const 1))
  (global $readptr (mut i32) (i32.const 0))
  (func $getchar
    (result i32)