Today, we’re excited to announce the launch of MetaMask Mobile! 🎉 Built with dApp discoverability in mind, MetaMask Mobile equips every smartphone user with the tools to explore and participate in Web3, securely. It’s free to download and available to all iPhone and Android users.

The app offers all the stuff you’d expect from an Ethereum wallet-like trading tokens and managing your digital assets. But unlike standard wallets, you can also use MetaMask Mobile to browse Web3, discover new dApps and interact with them-from anywhere, anytime. You can take Web3 with you, wherever you go.

Browse, Buy, Send, and Sign

We’re excited to start serving our massive user base on mobile and we’re incredibly inspired by what this product could potentially do for the +2 billion people worldwide who can only access the Internet through a mobile phone. By enabling mobile access to Web3, we hope our app creates the opportunity for a whole new generation of smartphone users to access a more transparent and security-focused Internet.

How to Get Started

• Take out your smartphone and head to the App Store or Google Play to download MetaMask Mobile.
• Open the app and MetaMask will step guide you through your account set up and wallet creation.
• Already a MetaMask user? Setting up the app is just as smooth. Open and connect to Web3 in a matter of seconds.

For Beta Testers

Testflight users currently using the beta version on iOS will continue to have access to it. However, to start using the production version of MetaMask Mobile, you’ll need to download the app from the Apple App Store and set up your wallet again using your wallet’s seed phrase or syncing with your MetaMask extension.

For Android users currently using the Open Beta version, the app will update seamlessly to the production version. If you have auto-updates enabled, there is no action required.

If you choose to leave the beta program, make sure you secure your wallet by saving your wallet seed phrase and the private keys for any imported accounts. Google Play Store may ask you to reinstall upon leaving the beta.

Here are a few how-to videos to help you manage your seed phrase and private keys:

• Find your seed phrase
• Secure your wallet
• Import account with private key

Want Web3 in Your Pocket?

Discover new dapps, trade digital assets, and more from anywhere.

Originally published at https://consensys.net.

MetaMask Mobile Now Available on Android and iOS! was originally published in MetaMask on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s Happening

On August 25th, 2020, JP Morgan and ConsenSys announced that the Quorum open source project would be acquired and managed by ConsenSys as part of a strategic investment by JPM.

The acquisition is a major step in the acceleration of enterprise adoption of blockchain technology and Ethereum-based solutions. By using Quorum with ConsenSys’ other enterprise product offerings, businesses can build highly customizable, secure, and performant solutions.

• Read the press release
• Visit the new Quorum website

What Is ConsenSys Quorum?

With this announcement, ConsenSys is pleased to announce its new open source protocol offering, ConsenSys Quorum. ConsenSys Quorum is an open source protocol layer that serves as a foundation for businesses to build public or private Ethereum-based enterprise solutions. ConsenSys Quorum is made up of four layers of open source codebase: client software, private transaction management, external transaction signing, and additional tooling.

For help with the implementation and maintenance of the open source layer, developers and businesses can request subscription-based support from ConsenSys Quorum Support. Our support team consists of developers and expert contributors across all the open source projects under ConsenSys Quorum.

On top of the open source layer, developers and businesses can also deploy a range of institutional-grade product features developed by ConsenSys to enable asset tokenization and management, payments, document management, workflow optimization, risk compliance, and more.

What the Acquisition Means for Businesses and Developers

The acquisition of Quorum by ConsenSys signals an important step in the ecosystem’s commitment to enterprise adoption and development. With Quorum, ConsenSys will expand its enterprise Ethereum offerings in three primary ways: 1) commitment to open source development, 2) aligned evolution and development for both private and public enterprise solutions, and 3) more robust production-grade features on top of open source codebases.

Commitment to Open Source Development

Under ConsenSys, ConsenSys Quorum will remain an open source codebase, available for anyone to begin building production-grade applications. Robust documentation will be maintained by the ConsenSys protocol engineering team. ConsenSys Quorum will continue ConsenSys’ long history of open source protocol development, particularly with the continued development of Hyperledger Besu, the mainnet-compatible Ethereum client.

ConsenSys also offers support subscriptions for ConsenSys Quorum to accelerate time to market and provide confidence in production networks. The goal is to ensure the ability to build blockchain-based solutions remains permissionless, while also providing support services to accelerate adoption if needed.

Private and Public Enterprise Solutions

To date, ConsenSys has maintained Hyperledger Besu, a mainnet-compatible Enterprise Ethereum client. Under JPM, Quorum has supported many enterprise-grade solutions on private Ethereum-based networks. With the acquisition, ConsenSys Quorum will align the development of both private-permissioned and mainnet-compatible enterprise solutions, enabling a more complete and robust evolution of blockchain technology among businesses. In the near future, ConsenSys will work towards making GoQuorum interoperable with Hyperledger Besu, aligning with ConsenSys’ vision of enabling both private and public network use cases.

Production-Grade Features and Services

With the acquisition, ConsenSys will accelerate the development of a suite of products that run on the ConsenSys Quorum open source protocol layer. These product modules enable a configurable approach to enterprise applications, allowing businesses across industries to build highly customized solutions to fit specific needs. The intention of these product modules-paired with the open source nature of the ConsenSys Quorum codebases-is to open the doors to theoretically limitless business adoption.

Altogether, the acquisition of Quorum solidifies ConsenSys as the go-to source for enterprises seeking to learn more about, explore options for, and eventually build production-grade solutions that fit their business needs.

A Detailed Look at ConsenSys Quorum: The Complete Open Source Blockchain Protocol Layer for Business

With the announcement of the acquisition, ConsenSys Quorum developers will have a choice of two open source stacks to build on: Go-based GoQuorum or Java-based Hyperledger Besu.

The Go-based stack (previously known as “Quorum” under JPM) includes the GoQuorum client software, the Tessera private transaction manager, and the EthSigner private key manager. The Java-based Hyperledger Besu stack will consist of the same projects that are known and used by ConsenSys today, recategorized under ConsenSys Quorum. The Java-based stack includes the Hyperledger Besu client software, the Orion private transaction manager, and the EthSigner external transaction signer.

With the announcement of the acquisition, Hyperledger Besu, Orion, EthSigner will be bundled in the ConsenSys Quorum offering along with GoQuorum and Tessera. As mentioned above, ConsenSys Quorum will now give developers the option to choose between the Go-based GoQuorum or Java-based Hyperledger Besu stacks. In the near future, we will be adding additional functionality to Quorum, enhancing the developer experience and providing value-added functionality further up the stack.

PegaSys Orchestrate will join the Codefi application suite as Codefi Orchestrate, a collection of core technical components for every enterprise blockchain solution. Codefi Orchestrate will include the expanded capabilities to accelerate the production of enterprise blockchain solutions, reduce development costs, and quicken time-to-market. It will connect a number of Codefi product modules and features with the Quorum open source protocol layer.

PegaSys Plus will be replaced by ConsenSys Quorum Support, a subscription-based support service providing developers and businesses with on-demand support for the Quorum open source protocol projects. ConsenSys Quorum Support also offers plugins, which extend the Hyperledger Besu Ethereum client and provide functionality to address additional enterprise requirements.

PegaSys Teku and R&D won’t be going anywhere. In the coming months, they will live elsewhere within ConsenSys, but the work will continue uninterrupted. For the time being, they can still be found on the PegaSys site.

Evolving and Accelerating Enterprise Adoption With ConsenSys Quorum

ConsenSys is building a suite of products that can be built on the ConsenSys Quorum open source protocol layer. These product modules enable businesses to build customizable solutions optimized for their specific industry needs. Among other features, these feature modules enable asset tokenization and management, payments, document management, workflow optimizatifon, and risk compliance.

The enterprise product modules are all compatible with the Quorum open source layer through Codefi Orchestrate. Orchestrate enables businesses to build blockchain-powered applications by simplifying the development and connectivity of business applications with the Ethereum blockchain.

How to Get Started With ConsenSys Quorum

Everything you need to get started with Quorum as either a developer or a business can be found on the ConsenSys Quorum site. Our developer page includes further information about the open source codebases and links to our documentation. Our product page explains the product modules available on top of Quorum and contact information to begin building enterprise applications on top of Quorum. If you are an enterprise or developer looking for hands-on support, contact us here.

Join our community

• ConsenSys Quorum Discord
• ConsenSys Quorum Twitter
• ConsenSys Quorum LinkedIn
• GoQuorum Slack
• Hyperledger Besu Rocketchat

Originally published at https://consensys.net.

ConsenSys Acquires J.P. Morgan’s Quorum to Advance Enterprise Blockchain Adoption was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

By ConsenSys Diligence, our team of blockchain security experts.

If you’ve taken the smart contract security mindset to heart and are getting a handle on the EVM’s idiosyncrasies, it’s time to consider some security patterns that are specific to the Solidity programming language. In this roundup, we’ll focus on secure development recommendations for Solidity that may also be instructive for developing smart contracts in other languages.

Okay, let’s jump in.

Use assert(), require(), revert() properly

The convenience functions assert and require can be used to check for conditions and throw an exception if the condition is not met.

The assert function should only be used to test for internal errors, and to check invariants.

The require function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts.

Following this paradigm allows formal analysis tools to verify that the invalid opcode can never be reached: meaning no invariants in the code are violated and that the code is formally verified.

pragma solidity ^0.5.0;

contract Sharer {
    function sendHalf(address payable addr) public payable returns (uint balance) {
        require(msg.value % 2 == 0, "Even value required."); //Require() can have an optional message string
        uint balanceBeforeTransfer = address(this).balance;
        (bool success, ) = addr.call.value(msg.value / 2)("");
        require(success);
        // Since we reverted if the transfer failed, there should be
        // no way for us to still have half of the money.
        assert(address(this).balance == balanceBeforeTransfer - msg.value / 2); // used for internal error checking
        return address(this).balance;
    }
}

See SWC-110 & SWC-123

Use modifiers only for checks

The code inside a modifier is usually executed before the function body, so any state changes or external calls will violate the Checks-Effects-Interactions pattern. Moreover, these statements may also remain unnoticed by the developer, as the code for modifier may be far from the function declaration. For example, an external call in modifier can lead to the reentrancy attack:

contract Registry {
    address owner;

    function isVoter(address _addr) external returns(bool) {
        // Code
    }
}

contract Election {
    Registry registry;

    modifier isEligible(address _addr) {
        require(registry.isVoter(_addr));
        _;
    }

    function vote() isEligible(msg.sender) public {
        // Code
    }
}

In this case, the Registry contract can make a reentracy attack by calling Election.vote() inside isVoter().

Note: Use modifiers to replace duplicate condition checks in multiple functions, such as isOwner(), otherwise use require or revert inside the function. This makes your smart contract code more readable and easier to audit.

Beware rounding with integer division

All integer division rounds down to the nearest integer. If you need more precision, consider using a multiplier, or store both the numerator and denominator.

(In the future, Solidity will have a fixed-point type, which will make this easier.)

// bad
uint x = 5 / 2; // Result is 2, all integer division rounds DOWN to the nearest integer

Using a multiplier prevents rounding down, this multiplier needs to be accounted for when working with x in the future:

// good
uint multiplier = 10;
uint x = (5 * multiplier) / 2;

Storing the numerator and denominator means you can calculate the result of numerator/denominator off-chain:

// good
uint numerator = 5;
uint denominator = 2;

Be aware of the tradeoffs between abstract contracts and interfaces

Both interfaces and abstract contracts provide one with a customizable and re-usable approach for smart contracts. Interfaces, which were introduced in Solidity 0.4.11, are similar to abstract contracts but cannot have any functions implemented. Interfaces also have limitations such as not being able to access storage or inherit from other interfaces which generally makes abstract contracts more practical. Although, interfaces are certainly useful for designing contracts prior to implementation. Additionally, it is important to keep in mind that if a contract inherits from an abstract contract it must implement all non-implemented functions via overriding or it will be abstract as well.

Fallback functions

Keep fallback functions simple

Fallback functions are called when a contract is sent a message with no arguments (or when no function matches), and only has access to 2,300 gas when called from a .send() or .transfer(). If you wish to be able to receive Ether from a .send() or .transfer(), the most you can do in a fallback function is log an event. Use a proper function if a computation of more gas is required.

// bad
function() payable { balances[msg.sender] += msg.value; }

// good
function deposit() payable external { balances[msg.sender] += msg.value; }

function() payable { require(msg.data.length == 0); emit LogDepositReceived(msg.sender); }

Check data length in fallback functions

Since the fallback functions is not only called for plain ether transfers (without data) but also when no other function matches, you should check that the data is empty if the fallback function is intended to be used only for the purpose of logging received Ether. Otherwise, callers will not notice if your contract is used incorrectly and functions that do not exist are called.

// bad
function() payable { emit LogDepositReceived(msg.sender); }

// good
function() payable { require(msg.data.length == 0); emit LogDepositReceived(msg.sender); }

Explicitly mark payable functions and state variables

Starting from Solidity 0.4.0, every function that is receiving ether must use payable modifier, otherwise if the transaction has msg.value > 0 will revert ( except when forced).

Note: Something that might not be obvious: The payable modifier only applies to calls from external contracts. If I call a non-payable function in the payable function in the same contract, the non-payable function won't fail, though msg.value is still set.

Explicitly mark visibility in functions and state variables

Explicitly label the visibility of functions and state variables. Functions can be specified as being external, public, internal or private. Please understand the differences between them, for example, external may be sufficient instead of public. For state variables, external is not possible. Labeling the visibility explicitly will make it easier to catch incorrect assumptions about who can call the function or access the variable.

• External functions are part of the contract interface. An external function f cannot be called internally (i.e. f() does not work, but this.f() works). External functions are sometimes more efficient when they receive large arrays of data.
• Public functions are part of the contract interface and can be either called internally or via messages. For public state variables, an automatic getter function (see below) is generated.
• Internal functions and state variables can only be accessed internally, without using this.
• Private functions and state variables are only visible for the contract they are defined in and not in derived contracts. Note: Everything that is inside a contract is visible to all observers external to the blockchain, even Private variables.

// bad
uint x; // the default is internal for state variables, but it should be made explicit
function buy() { // the default is public
    // public code
}

// good
uint private y;
function buy() external {
    // only callable externally or using this.buy()
}

function utility() public {
    // callable externally, as well as internally: changing this code requires thinking about both cases.
}

function internalAction() internal {
    // internal code
}

See SWC-100 and SWC-108

Lock pragmas to specific compiler version

Contracts should be deployed with the same compiler version and flags that they have been tested the most with. Locking the pragma helps ensure that contracts do not accidentally get deployed using, for example, the latest compiler which may have higher risks of undiscovered bugs. Contracts may also be deployed by others and the pragma indicates the compiler version intended by the original authors.

// bad
pragma solidity ^0.4.4;


// good
pragma solidity 0.4.4;

Note: a floating pragma version (ie. ^0.4.25) will compile fine with 0.4.26-nightly.2018.9.25, however nightly builds should never be used to compile code for production.

Warning: Pragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package. Otherwise, the developer would need to manually update the pragma in order to compile locally.

See SWC-103

Use events to monitor contract activity

It can be useful to have a way to monitor the contract’s activity after it was deployed. One way to accomplish this is to look at all transactions of the contract, however that may be insufficient, as message calls between contracts are not recorded in the blockchain. Moreover, it shows only the input parameters, not the actual changes being made to the state. Also events could be used to trigger functions in the user interface.

contract Charity {
    mapping(address => uint) balances;

    function donate() payable public {
        balances[msg.sender] += msg.value;
    }
}

contract Game {
    function buyCoins() payable public {
        // 5% goes to charity
        charity.donate.value(msg.value / 20)();
    }
}

Here, Game contract will make an internal call to Charity.donate(). This transaction won't appear in the external transaction list of Charity, but only visible in the internal transactions.

An event is a convenient way to log something that happened in the contract. Events that were emitted stay in the blockchain along with the other contract data and they are available for future audit. Here is an improvement to the example above, using events to provide a history of the Charity’s donations.

contract Charity {
    // define event
    event LogDonate(uint _amount);

    mapping(address => uint) balances;

    function donate() payable public {
        balances[msg.sender] += msg.value;
        // emit event
        emit LogDonate(msg.value);
    }
}

contract Game {
    function buyCoins() payable public {
        // 5% goes to charity
        charity.donate.value(msg.value / 20)();
    }
}

Here, all transactions that go through the Charity contract, either directly or not, will show up in the event list of that contract along with the amount of donated money.

Note: Prefer newer Solidity constructs. Prefer constructs/aliases such as selfdestruct (over suicide) and keccak256 (over sha3). Patterns like require(msg.sender.send(1 ether)) can also be simplified to using transfer(), as in msg.sender.transfer(1 ether). Check out Solidity Change log for more similar changes.

Be aware that “Built-ins” can be shadowed

It is currently possible to shadow built-in globals in Solidity. This allows contracts to override the functionality of built-ins such as msg and revert(). Although this is intended, it can mislead users of a contract as to the contract's true behavior.

contract PretendingToRevert {
    function revert() internal constant {}
}

contract ExampleContract is PretendingToRevert {
    function somethingBad() public {
        revert();
    }
}

Contract users (and auditors) should be aware of the full smart contract source code of any application they intend to use.

Avoid using tx.origin

Never use tx.origin for authorization, another contract can have a method which will call your contract (where the user has some funds for instance) and your contract will authorize that transaction as your address is in tx.origin.

contract MyContract {

    address owner;

    function MyContract() public {
        owner = msg.sender;
    }

    function sendTo(address receiver, uint amount) public {
        require(tx.origin == owner);
        (bool success, ) = receiver.call.value(amount)("");
        require(success);
    }

}

contract AttackingContract {

    MyContract myContract;
    address attacker;

    function AttackingContract(address myContractAddress) public {
        myContract = MyContract(myContractAddress);
        attacker = msg.sender;
    }

    function() public {
        myContract.sendTo(attacker, msg.sender.balance);
    }

}

You should use msg.sender for authorization (if another contract calls your contract msg.sender will be the address of the contract and not the address of the user who called the contract).

You can read more about it here: Solidity docs

Warning: Besides the issue with authorization, there is a chance that tx.origin will be removed from the Ethereum protocol in the future, so code that uses tx.origin won't be compatible with future releases Vitalik: 'Do NOT assume that tx.origin will continue to be usable or meaningful.'

It’s also worth mentioning that by using tx.origin you're limiting interoperability between contracts because the contract that uses tx.origin cannot be used by another contract as a contract can't be the tx.origin.

See SWC-115

Timestamp dependence

There are three main considerations when using a timestamp to execute a critical function in a contract, especially when actions involve fund transfer.

Timestamp manipulation

Be aware that the timestamp of the block can be manipulated by a miner. Consider this contract:

uint256 constant private salt =  block.timestamp;

function random(uint Max) constant private returns (uint256 result){
    //get the best seed for randomness
    uint256 x = salt * 100/Max;
    uint256 y = salt * block.number/(salt % 5) ;
    uint256 seed = block.number/3 + (salt % 300) + Last_Payout + y;
    uint256 h = uint256(block.blockhash(seed));

    return uint256((h / x)) % Max + 1; //random number between 1 and Max
}

When the contract uses the timestamp to seed a random number, the miner can actually post a timestamp within 15 seconds of the block being validated, effectively allowing the miner to precompute an option more favorable to their chances in the lottery. Timestamps are not random and should not be used in that context.

The 15-second Rule

The Yellow Paper (Ethereum’s reference specification) does not specify a constraint on how much blocks can drift in time, but it does specify that each timestamp should be bigger than the timestamp of its parent. Popular Ethereum protocol implementations Geth and Parity both reject blocks with timestamp more than 15 seconds in future. Therefore, a good rule of thumb in evaluating timestamp usage is: if the scale of your time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use a block.timestamp.

Avoid using block.number as a timestamp

It is possible to estimate a time delta using the block.number property and average block time, however this is not future proof as block times may change (such as fork reorganisations and the difficulty bomb). In a sale spanning days, the 15-second rule allows one to achieve a more reliable estimate of time.

See SWC-116

Multiple inheritance caution

When utilizing multiple inheritance in Solidity, it is important to understand how the compiler composes the inheritance graph.

contract Final {
    uint public a;
    function Final(uint f) public {
        a = f;
    }
}

contract B is Final {
    int public fee;

    function B(uint f) Final(f) public {
    }
    function setFee() public {
        fee = 3;
    }
}

contract C is Final {
    int public fee;

    function C(uint f) Final(f) public {
    }
    function setFee() public {
        fee = 5;
    }
}

contract A is B, C {
  function A() public B(3) C(5) {
      setFee();
  }
}

When a contract is deployed, the compiler will linearize the inheritance from right to left (after the keyword is the parents are listed from the most base-like to the most derived). Here is contract A’s linearization:

Final <- B <- C <- A

The consequence of the linearization will yield a fee value of 5, since C is the most derived contract. This may seem obvious, but imagine scenarios where C is able to shadow crucial functions, reorder boolean clauses, and cause the developer to write exploitable contracts. Static analysis currently does not raise issue with overshadowed functions, so it must be manually inspected.

For more on security and inheritance, check out this article

To help contribute, Solidity’s Github has a project with all inheritance-related issues.

See SWC-125

Use interface type instead of the address for type safety

When a function takes a contract address as an argument, it is better to pass an interface or contract type rather than raw address. If the function is called elsewhere within the source code, the compiler it will provide additional type safety guarantees.

Here we see two alternatives:

contract Validator {
    function validate(uint) external returns(bool);
}

contract TypeSafeAuction {
    // good
    function validateBet(Validator _validator, uint _value) internal returns(bool) {
        bool valid = _validator.validate(_value);
        return valid;
    }
}

contract TypeUnsafeAuction {
    // bad
    function validateBet(address _addr, uint _value) internal returns(bool) {
        Validator validator = Validator(_addr);
        bool valid = validator.validate(_value);
        return valid;
    }
}

The benefits of using the TypeSafeAuction contract above can then be seen from the following example. If validateBet() is called with an address argument, or a contract type other than Validator, the compiler will throw this error:

contract NonValidator{}

contract Auction is TypeSafeAuction {
    NonValidator nonValidator;

    function bet(uint _value) {
        bool valid = validateBet(nonValidator, _value); // TypeError: Invalid type for argument in function call.
                                                        // Invalid implicit conversion from contract NonValidator
                                                        // to contract Validator requested.
    }
}

Avoid using extcodesize to check for externally owned accounts

The following modifier (or a similar check) is often used to verify whether a call was made from an externally owned account (EOA) or a contract account:

modifier isNotContract(address _a) { uint size; assembly { size := // bad
modifier isNotContract(address _a) {
  uint size;
  assembly {
    size := extcodesize(_a)
  }
    require(size == 0);
     _;
}

The idea is straight forward: if an address contains code, it’s not an EOA but a contract account. However, a contract does not have source code available during construction. This means that while the constructor is running, it can make calls to other contracts, but extcodesize for its address returns zero. Below is a minimal example that shows how this check can be circumvented:

contract OnlyForEOA {    
    uint public flag;

    // bad
    modifier isNotContract(address _a){
        uint len;
        assembly { len := extcodesize(_a) }
        require(len == 0);
        _;
    }

    function setFlag(uint i) public isNotContract(msg.sender){
        flag = i;
    }
}

contract FakeEOA {
    constructor(address _a) public {
        OnlyForEOA c = OnlyForEOA(_a);
        c.setFlag(1);
    }
}

Because contract addresses can be pre-computed, this check could also fail if it checks an address which is empty at block n, but which has a contract deployed to it at some block greater than n.

Warning: This issue is nuanced. If your goal is to prevent other contracts from being able to call your contract, the extcodesize check is probably sufficient. An alternative approach is to check the value of (tx.origin == msg.sender), though this also has drawbacks.

There may be other situations in which the extcodesize check serves your purpose. Describing all of them here is out of scope. Understand the underlying behaviors of the EVM and use your judgement.

More on this topic:

• The Smart Contract Security Mindset
• Ethereum Smart Contract Security Recommendations

Originally published at https://consensys.net.

Solidity Best Practices for Smart Contract Security was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Automated Verification team on ConsenSys R&D have been working on a formal specification and verification of the Beacon Chain for a few months. We are happy to report that lots of progress has been made and although not complete yet, we have managed to develop a solid and formally verified kernel of the Beacon Chain. For the first time, our work provides an unmatched level of trustworthiness to the core foundations of the Ethereum 2.0 infrastructure.

Methodology

Verification vs. Testing

We used the award-winning verification-aware programming language Dafny to write a (functional and logical) specification of each Beacon Chain function, an implementation of each function, and a that the implementation conforms to its specification. In other words, we have mathematically verified the absence of bugs. The implementations that we have eventually proved correct are based on the official Eth2.0 specifications with the caveat that we have fixed and reported some bugs and inconsistencies.

Our methodology is different to testing as we mathematically prove conformance of the functions to their specifications, for inputs. Testing cannot range over infinitely many inputs, and as a consequence can discover bugs but not prove the absence of bugs.

And the best thing is that we do not need to publish a paper nor to review the proofs. The proofs are part of the code base and written as programs. Yes, in Dafny, you can write a proof as a developer-friendly program. Also, the proofs are mechanically checked by a theorem prover, leaving no room for incomplete or flawed proofs.

Properties We Have Proved

The properties range from the absence of arithmetic under/overflows and index out of bounds, the conformance of each function to logical (first-order logic) pre/post-conditions ( merkelise example here), to more complex ones involving functions’ compositions. For example, we have the following property of the SSZ Serialise/Deserialise functions: for each object x, Deserialise(Serialise(x)) = x, i.e. deserialising a serialised object returns the original object. We have also established a number of invariants, and used them to prove that the core operations of the Beacon Chain and ForkChoice ( state_transition, on_block) actually build a chain of blocks: for any block b in the store, the ancestors of b form a finite totally ordered sequence leading to the genesis block, which is the main property of a blockchain!

The Benefits of Formal Verification

Any formal methodist would insist that verification is a security best practice. Here’s exactly how this methodology ensures a secure and trustworthy infrastructure for Ethereum 2.0.

Functional Specification

First, we have lifted the official Eth2.0 specifications to a formal logical and functional specification. For each function, we formally define what the function is expected to compute, not how. This provides language-agnostic developer-friendly reference specifications that can be used to develop more secure implementations, with less effort.

Modularity

Second, our specifications, implementations and proof architecture are . As a result, we can easily experiment with new implementations (e.g. optimisations) and check their impact on the overall system. Think of a clever hack to implement a function? Change the implementation and ask Dafny to check that it still conforms to its specification. If it does, the proofs of the components that use this function are not impacted.

Executability

Third, our implementations are executable. We can compile and run a Dafny program. Even better, you can automatically generate code in some popular programming languages like C#, Go (and soon Java) from the Dafny code. This can be used to complement existing code bases or to generate certified tests. The implementation to be tested can use our proved-correct functions to compute the expected result of a test and check it against its own result.

Everything in a Single Language

Last but not least, our code base is self-contained. It contains the specifications, implementations, documentations, and proofs, all in a single, readable, simple and semantically well-defined programming language.

Questions and Considerations

What about the soundness of the verification engine?

You might be wondering, “what if the Dafny compiler/verifier is buggy?” We actually know Dafny is buggy (dafny repo issues), but we do not rely on the absence of bugs in Dafny. We rely on Dafny (and its verification engine) to be . Soundness means that when Dafny reports that proofs are correct, they are indeed correct.

What if the specification we have written is not the right one?

In this case, we would prove conformance to a wrong requirement. Yes, this can happen and there is no silver bullet to fix this problem. However, as we mentioned before, Dafny is executable. This enables us to run the code and get some confidence that our specifications are the right ones. And our specifications are written in first-order logic with no room for dispute about the meaning, so if you notice a problem, let us know and we will fix it.

What if Dafny cannot prove that an implementation conforms to a specification?

This can happen, but in this case Dafny has some feedback mechanisms to help investigate what steps of a proof cannot be verified. And until now, we have always managed to build proofs that Dafny can automatically check.
We welcome your feedback, so please check out our eth2.0-dafny repository. We’ve been excited to watch Ethereum 2.0 development reach its recent testnet milestones, and we look forward to working with teams across the ecosystem to ensure the next phase of the network is built on a rock solid foundation.

Acknowledgement: Thanks to my teammates Joanne Fuller, Roberto Saltini (Automated Verification team), Nicolas Liochon, and to Avery Erwin for comments on a preliminary version of this post.

Read More About Ethereum 2.0

• What Is Ethereum 2.0?
• Ethereum 2.0 Glossary
• Ethereum 2.0 FAQ
• Ethereum 2.0 Knowledge Base

Originally published at https://consensys.net.

Formally Verifying the Ethereum 2.0 Phase 0 Specifications was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following is an excerpt of DeFi Dad’s closing commentary from the Q2 Ethereum DeFi Report. For tutorials on DeFi basics, yield farming, and more, check out his YouTube Channel.

Years from now, I believe Q2 2020 will be looked upon as a turning point in the rise of DeFi and a cementing of Ethereum’s inescapable network effects. Everything worth building is being built on Ethereum, and the narrative fueling this sentiment is the drive to build a new alternative P2P finance system. We’re talking about money legos that stack together to save us time, save us money, and enable greater global access in applications with remarkably low fees, remarkably high yield, and the absence of middlemen.

Q1 already brought about the very public milestone of $1 billion total value locked TVL deposited into DeFi applications, but it was unexpectedly followed by the global economic downturn associated with the coronavirus pandemic. I could have never predicted that after a near 50% drawdown in prices across cryptoasset markets to end Q12020, Q2 would rebound to a new historic milestone of $4 billion deposited into DeFi applications and protocols.

There’s something for everyone in DeFi.

Beyond the flashy numbers and hard hitting data you’ll discover in this report, there’s a simple explanation for all this growth: there’s something for everyone in DeFi. The composability of DeFi money legos combined with the largest community of Ethereum developers by many orders of magnitude has resulted in new P2P money applications for lending, borrowing, trading, stablecoins swaps, DEX aggregators, margin trading, futures, BTC futures, tokenized BTC, options, derivatives for commodities and forex, and newly launched ETF-like exposure thanks to Balancer. Most of this was either launched or made widely available for use in Q2-over just 3 months.

DeFi on Ethereum has seen more innovation in 3 months than legacy finance has seen in 3 decades.

It’s not complicated when you use these applications regularly and recognize not only do they work, but they impart an asymmetric value that our community would be devastated to lose access to. If you can recall having first experienced the likes of email, AOL Instant Messenger, and Napster, you cannot un-see such revolutionary value. DeFi is doing to money what email did to the postal service.

Thanks to the variety of DeFi applications built on Ethereum, there’s something for everyone to benefit from. It would be a shame for you to read this ecosystem report of rich data and insights and not follow up by actually trying one of many DeFi applications revolutionizing how future generations will transact peer-to-peer, but one quick warning: once you see this, there’s no turning back.

Download the Q2 Ethereum DeFi Report

Discover the biggest trends in decentralized finance.

Originally published at https://consensys.net.

DeFi Is Doing to Money What Email Did to the Postal Service was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. First, no one’s heard of you.
2. Then they’ve heard of you but think you’re nuts.
3. Then they understand your product, but think it has no opportunity.
4. Then they view your product as a toy.
5. Then they see it as an amazing toy.
6. Then they start using it.
7. Then they couldn’t imagine life without it.

–Morgan Housel, “When You Change the World and No One Notices”

No One’s Heard of You

Ethereum is now the most actively developed, most transacted upon blockchain network in the world. But five years ago today, when the genesis block was mined into existence and the network officially launched, few people outside of software engineering circles had heard of the Ethereum blockchain.

Ethereum: Bitcoin Plus Everything

In Goldman Sachs’ 2015 landmark report, “What If I Told You The Blockchain Could Disrupt Everything,” Ethereum was listed as a “startup.” Elsewhere it was described as a “group.” People were trying to understand what it was and exactly what made it different from Bitcoin, a digital cash system. At ConsenSys, we spent, and still spend, a good chunk of time explaining these differences. They can’t be emphasized enough:

• Bitcoin is a single application of blockchain technology.
• There are many different types of blockchains, with very different properties.
• Ethereum is one type of blockchain.
• Ethereum is open source and therefore owned by everyone.

If you want to know what blockchains mean for the future of human networks and the distribution of power, this tweetstorm from Naval Ravikant is a good place to start.

The Developer’s Blockchain

The Ethereum blockchain was built according to five design principles, outlined in Vitalik Buterin’s Ethereum White Paper:

• Simplicity
• Universality
• Modularity
• Agility
• Non-discrimination and non-censorship

One way to think about it is, if someone asked you to build a machine that took these principles to their logical limit, you’d end up with a machine like Ethereum.

In their book Mastering Ethereum, Andreas Antonopoulos and Gavin Wood call Ethereum the “developer’s blockchain, built by developers for developers.” Developers generally prefer software that is open, usable, programmable, and powerful. Thousands and then hundreds of thousands of devs gravitated toward Ethereum because the source code is free, you can build on what others have built, the smart contracts are standardized and templatizable, and the possibilities are endless when you start interlocking contracts and plugging in different data feeds.

State of the Dapps did a huge service to the ecosystem when it started digging into dapp contracts and fingerprinting GitHub repos, uncovering the frenzy of behind-the-scenes developer activity on Ethereum. When the New York Times published “Beyond the Bitcoin Bubble,” it felt like people were finally paying attention. Bitcoin was just the tip of the blockchain iceberg, and it was only a matter of time before the rest of the world followed the developers.

They Think You’re Nuts

The DAO

In 2016, the DAO hack, and the hard fork that followed, caught everyone’s attention. Some people thought this Ethereum thing was nuts. What happened, the press said, “raises philosophical questions about the viability of such systems.”

But developers said, “This is a rite of passage.”

The community got to work documenting known attacks and battle-testing smart contract libraries. While there has been no shortage of security incidents over the years, decentralized autonomous organizations are now a staple of the Ethereum ecosystem (Aragon, Moloch DAO, Legal DAO, Maker DAO), and hard forks are a proven model for upgrading the network’s protocol.

Positive Sum Thinking

Think about what else used to be “nuts” in our ecosystem:

• Enterprises operating on a public network
• Different blockchains working together

100-year-old firms like Ernst & Young are now using zero-knowledge proofs to develop private transaction solutions on the public Ethereum network. And they’re collaborating with a fleet of other organizations to push the Baseline Protocol forward and help enterprises onboard to mainnet.

Ethereum and Hyperledger, once perceived as rival DLT initiatives, are now fully integrated via Besu, Burrow, and Sawtooth. Even Fabric supports Ethereum smart contracts.

The maximalist, one-blockchain-to-rule-them-all thinking that characterized the early days of the cryptosphere has fallen away in favor of a grander vision of interoperating blockchain protocols. Over the past few months, we’ve seen a huge uptick in “wrapped bitcoin” -bitcoin represented as ERC-20 tokens on Ethereum that allow bitcoin holders to participate in the decentralized finance protocols that are not available on the Bitcoin network.

The point is, the positive sum thinking of early adopters that once seemed far-fetched and technically impossible is now more and more a reality. In the words of Jeff Bezos, “Invention requires a long-term willingness to be misunderstood.”

They Understand It But…

ICO Fever

In early 2018, the blockchain and Ethereum community was still reeling from the shock that 2017 had sent through the cryptosphere. The ICO boom of 2017 had initiated one of the greatest bull markets in Ethereum’s history on the backs of considerable speculation and unprecedented ERC-20 token launches. The boom demonstrated first-hand the power of the network effect opportunities at the core of blockchain technology. However, a number of countries-China, South Korea, Morocco, Colombia, Singapore, and many others-issued either bans or severe warnings to their citizens about bitcoin, ether, and other crypto assets.

When the glow of $1000+ ETH prices wore off and crypto winter descended, the industry began reconsidering the past year of ICOs and reckoning with its darker legacies. Fortune reported that nearly 50% of all ICO projects had already failed by February. The Verge published a sobering report on the mental health and despair of many South Korean millennials in the aftermath of the crypto bull market.

Today, there are over 160k ERC-20 token contracts on the Ethereum network. Many were created in early 2018 during the height of the ICO boom. In the last few months of this year, we have seen the creation of ERC-20 tokens begin to increase towards similar levels, yet without the price volatility we all experienced in late 2017 and early 2018.

“Ethereum Killers”

The ICO boom and its aftermath provided rich soil for a crop of new programmable blockchains, many of which positioned their technology as the replacement of Ethereum. The most notable of these “Ethereum killers” was EOS, which released a white paper in 2017.

The post-ICO marketing narratives of new blockchains focused largely on the shortcomings of Ethereum: scalability, privacy, UX, and utility. Some of these shortcomings were perceived, some real, and some exaggerated.

Altogether, the Ethereum ICO boom and aftermath had many understanding the technology, but still searching for compelling use cases and opportunities. One silver lining of the crypto boom and winter was that it spurred us to pay attention to lower-level and perhaps more revealing blockchain metrics beyond price and transaction volume: smart contract deployments, decentralization, and risk.

They Think It’s a Toy

On-Ramps and NFTs

As the Ethereum community developed new token standards like ERC-721, gaming and art emerged as fun onramps to the underlying blockchain technology. And it made sense: games have built-in micro-economies and collectibles, and digital art that was hashed to the blockchain was easily monetizable and provably authentic. Marketplaces like SuperRare popped up for digital artwork. People talked about “proof of taste.”

CryptoKitties

The viral sensation that first shock-loaded the Ethereum network was an unassuming dapp called CryptoKitties, a digital kittens trading game that seemed like a cross between Neopets and futures trading. In December 2017, total network requests more than doubled as prices for the CryptoKitties surged into the six figures. A taskforce of developers from MetaMask, Infura, Grid+, and Axiom Zen came together to optimize UX and explore longer-term scaling solutions to relieve the congestion. In collaborating, they realized something profound about Ethereum protocol development. As Alex Miller from Grid+ noted, “Everyone who owns ether is incentivized to make the system better.”

People also realized that gamers and artists were running businesses straight out of their Ethereum wallets. Devs had unlocked economic models where previously none had existed. They brought finance to gaming-now it was time to see if they could gamify finance.

They Think It’s an Amazing Toy

The Rise of DeFi

There’s an argument that all of Ethereum is decentralized finance (DeFi). At its core, the blockchain is maintained by a network of incentivized miners who continue spending resources in order to receive a decentralized currency as a reward. That accumulated currency is then sold to other people and enters into the ecosystem.

DeFi as it is more commonly understood, however-as a set of interconnected protocols that have the opportunity to supplant the traditional financial vehicles of today-emerged onto the scene in late 2017 with MakerDAO’s release of DAI. MakerDAO allowed ETH to be locked into the smart contract and the DAI stablecoin to be taken out as collateral. After that moment, the Ethereum DeFi ecosystem grew steadily, largely still dominated by MakerDAO.

2019 was the year of DeFi, but its influence still remained constricted largely to the community of people who were already familiar with the technology and had been working in the ecosystem for some time. Many companies were building DeFi protocols, but overall, the UX felt rudimentary and the capabilities still fairly limited except for the most skilled DeFi users.

In the early months of 2019, the DeFi ecosystem was in many ways a sandbox, where Ethereum enthusiasts were road testing these open protocols and proving out the case for decentralized finance. In the aftermath of the 2018 bear market, ETH holders may have felt cautious about “putting their ETH to work” rather than HODLing in the hopes of another bull market.

Financial Primitives and Money Legos

Financial primitives are the basic decentralized financial capabilities and technologies that can be combined or built on top of by others in order to create more complex and/or specific applications. These financial primitives and the applications built on top function a bit like legos, to use a popular analogy. Money legos stacked on top of money legos stacked on top of more money legos creates an interwoven, interconnected financial structure that is both strong and customizable.

These money legos reached critical mass in late 2019, hurling us into 2020 and taking DeFi from the status of “amazing toy” to the early stages of a critical tool for reimagining our financial infrastructure.

They Start Using It

Software Eats Finance

Five years ago, it would have seemed outlandish to “move $15 trillion of global gross domestic product to open source programmable blockchains.” Now that seems like the only way to bring speed, resilience, transparency, and ultimately trust to our global financial system, which is still running on 30-year-old banking software.

Forward-thinking enterprises followed the developers and have been investing in Ethereum for years now. Our partnership with Microsoft starting in 2015 was one of our earliest efforts to help enterprises adopt blockchain tech via Ethereum Blockchain as a Service on Azure. The Enterprise Ethereum Alliance and Hyperledger have also become valuable environments for large institutions to actively collaborate, vet deployment options, and develop common enterprise standards.

The Institutional Herd

So who are the major players using Ethereum? It’s a long list. Trade finance giants. Agritech giants. 32 of the Forbes Blockchain 50 projects this year are built on Ethereum. Now, the powerhouses are moving in. The Depository Trust & Clearing Corporation, which processes around $2 quadrillion worth of transactions per year, recently announced an Ethereum-based prototype for digital asset management.

New initiatives are constantly sprouting up. In their final report last month, the EU Blockchain Observatory and Forum shared a crowdsourced blockchain initiative map that now charts over 700 initiatives worldwide.

Some of these projects are still very exploratory. Three-hundred-year-old central banks, for example, won’t adopt blockchain-based payments systems overnight. But according to a recent paper from the Bank for International Settlements, 80% of these legacy institutions are actively researching central bank digital currency (CBDC). The incumbents are realizing that in a world with super apps, bundled services, and an increasingly digital economy, Ethereum is not just the infrastructure they need to do bigger business with one another, but their lifeline for serving the 21st-century customer.

Plug-and-Play Ethereum

Since the beginning, ConsenSys’ mission has been to build enough infrastructure and tooling to enable the rest of the world to keep building a new trust infrastructure alongside us. We often liken this process to building a rocket ship mid-flight. The stakes are incredibly high and there’s no stopping now.

Over the past year, we’ve been working hard to bring our products together into a full stack, integrated suite that makes Ethereum more plug-and-play than ever before, whether you’re a dapp team that needs API access to node infrastructure or a financial institution that is ready to optimize business processes and digitize financial instruments. With a layer 2 solution like the SKALE Network shaping up and Ethereum 2.0 on the horizon, we’re excited to see how new and improved usability and network performance unlocks developers, enterprises, and the next wave of super users.

They Can’t Imagine Life Without It

This chapter of the seven-step path to the big breakthrough is still being written and will unfold slowly but surely in the years to come. Innovation of this scale often can’t be measured in quarters or even years. However, we like to think that there are some users-and some major institutions-who already can’t imagine life without Ethereum.

Thank you all of you across the ecosystem for your support, enthusiasm, and tireless work these past five years. Upgrading our global infrastructure is no small feat, but it is a worthwhile and profoundly rewarding one. We can’t wait to see what this network looks like in another five years.

Some Recommended Resources for Exploring Ethereum

• Blockchain Knowledge Base
• Ethereum 2.0 Knowledge Base
• Blockchain Webinars
• Want to Really Understand Blockchain? You Need to Understand State

Originally published at https://consensys.net.

The State of the Ethereum Network: 5 Years Running was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like all great missions, launching the world computer of tomorrow requires a platform that guides, strengthens, and fuels its journey across the bounds of our digital space. Today, we are excited to announce the go-live of the Eth2 Launch Pad application, which marks the entry point for validators to commence their journey on the Eth2 chain. It’s time to get your testnet ETH ready!

Over the past few months, Codefi Activate and the Ethereum Foundation (EF) have been heads down to make it easier for users to stake and become a validator on Ethereum 2.0. The result of this effort is the Eth2 Launch Pad, an application designed to securely guide you through the process of generating your Eth2 key pairs and staking your 32ETH into the official deposit contract. The Launch Pad was designed for self-validators, that is, hobbyists who intend to run their own validator and are comfortable running commands in a terminal screen on their computer.

Initially, the Launch Pad will only be compatible with the Eth2 Medalla testnet , which is scheduled to go-live once the genesis threshold of 16,384 validators (524,288 ETH) is met. The testnet is designed to provide ample time to ensure the Beacon Chain functions without error. Following the testnet phase, the Eth2 Launch Pad will continue to act as an entry portal for validators to stake real ETH for the Mainnet.

In this post, we will provide a brief overview of the collaboration, some fun facts about the application, as well as the needs and design goals that the Eth2 Launch Pad fulfills.

We look forward to providing the community with ongoing educational fuel and software tools to catalyze participation in this next chapter.

Joining Forces: A Background on the Collaboration

In 2019, we began digging into the Eth2 ecosystem to explore where Codefi Activate could add value to the roll out of Eth2 and fill existing communication gaps between the protocol builders, service providers and existing ETH holders with the approaching release of Phase 0. We have since focused our mission on developing educational resources and insights on Eth2 economics, as well as industry and validator research, the findings of which were recently released as the Eth2 staking ecosystem report .

Shortly after DevCon V we connected with Carl Beekhuizen, who was leading the deposit Command-Line-Interface (CLI) effort at the Ethereum Foundation (EF). Beyond the code, Carl has also focused on the user experience of ETH holders becoming validators for the first time. Given our existing Eth2 research efforts and our experience with launching networks, collaborating with the EF and Deep Work Studio was a congruent next step to ensuring the launch of Phase 0 was built in a way that prioritized user experience, but also articulated associated risks and educational information for users to feel comfortable setting up their own Eth2 validators.

Over the past few months we have been hard at work researching, designing, and building the Eth2 Launch Pad and we’re excited to share the outputs of this effort with you!

The Eth2 Launch Pad was open-sourced during the Ethereal Summit on May 8th, allowing users to host the application locally. Since its initial release, it has been great to see immediate engagement and feedback from the community. We continue to encourage teams and users to provide feedback!

Fun Facts

• The Eth2 Launch Pad mascot is Leslie the Rhino, named after the American computer scientist Leslie Lamport.
• The Eth2 spec repo currently has 72 direct contributors.
• The Eth2 deposit contract for the testnet will simulate the requirement to reach a Genesis threshold of 524,288 ETH staked or 16,384 validators

Getting to Genesis: A Brief Summary of Phase 0

Ethereum 2.0 will be released in phases, starting in 2020 with Phase 0. Phase 0 will launch the beacon chain, which is the component of the Ethereum 2.0 blockchain that implements the Proof of Stake consensus mechanism. The beacon chain will manage the registry of validators, who will begin attesting and proposing blocks.

In order for the beacon chain to launch its genesis block on mainnet, at least 524,288 ETH must be staked on the network, divided among a minimum of 16,384 validators to ensure sufficient security and decentralization. Reaching genesis will be simulated on the live Medalla testnet.

Each validator instance will require a deposit of 32 ETH to be added to the activation queue and begin attesting and proposing blocks on the beacon chain. Until withdrawals are enabled (at least after Phase 0), depositing ETH in the deposit contract is a one-way, non-reversible process.

What needs does the Eth2 Launch Pad fulfill?

Validators losing ETH = Eth2 losing validators

Simply put, if validators lose their ETH, Eth2 will lose validators. The process of depositing your ETH into the Eth2 deposit contract could result in multiple possible errors or attack vectors. These risks include losing your funds due to sending them to the wrong deposit contract address, falling prey to phishing attacks or someone stealing your private key and mnemonic phrase if generated and stored in an insecure manner. No one wants unhappy validators with lost or stolen funds!

To mitigate these risks, the Eth2 Launch Pad was designed as a front-end application designed to guide you through the process of generating your key pairs, depositing your ETH, and registering your validator on the Ethereum 2.0 beacon chain in the most secure way possible. The deposit interface will be hosted by the Ethereum Foundation.

During your journey through the Eth2 Launch Pad, you will:

1. Learn about the risks and responsibilities of becoming a validator on Eth2
2. Select how many validators instances you would like to run
3. Securely generate the validator key pair and mnemonic phrase, via an offline CLI for each validator instance you would like to run
4. Generate and upload the deposit data file(s) containing your validator public key(s) required to register your validator(s) upon completion of the Launch Pad
5. Deposit 32 ETH per validator instance into the official deposit contract. This will be done through a trusted and verified access point hosted by the Ethereum Foundation.

Education

Before you start your journey as a validator, it is paramount that you are aware of your responsibilities, including the rewards of fulfilling your duties to provide uptime and behave honestly in the consensus process, as well as the risks and penalties of failing to do so. Because the initial deposit of ETH into the deposit contract is one-way until later development phases, outlining and understanding the trade-offs of participation and setting expectations is critical.

For this reason, the Launch Pad was designed to act as both a deposit application as well as an educational tool box and source of truth curated to educate future validators about:

Warning messages and explanatory sections introduce “deliberate friction” in the user experience to slow down users and ensure they take in all the critical context provided to them.

Key Pair Generation

Validators using the Launch Pad will be required to generate their mnemonic and validator key pairs, which will be used when validators are ready to launch their respective validator clients. The public key allows you to view your validator stats and activity, while your private validator key, which must remain online at all times, is used for voting and proposing blocks.

In the Launch Pad, validators will also generate a mnemonic phrase to generate their withdrawal keys. During Phase 2, this mnemonic phrase will enable you to generate the keys to your castle, which will allow you to withdraw your ETH deposit and accrued rewards.

The generation of the validator key pair and mnemonic phrase has been designed to be done via a CLI to enable this process to be done in a secure, offline environment.

We are thrilled to have helped pave the way for initial deposits on the Ethereum 2.0 test- and mainnet and are excited to see applications and client integrations develop alternative pathways to interact with the Eth2 deposit contract in the future. A special shoutout to Chris Battenfield and George Weiler for their development work on this effort.

Watch this space for some more exciting announcements from our team!

Written by Collin Myers and Mara Schmiedt.

More on this topic

• Ethereum 2.0 Knowledge Base
• What Is Ethereum 2.0?
• What Is Proof of Stake?

Originally published at https://codefi.consensys.net on July 27, 2020.

Introducing the Deposit Launch Pad for Ethereum 2.0 was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

Activate, by ConsenSys Codefi, is the first platform designed to launch decentralized networks and allow customers to purchase, manage, and use their tokens in one application. The SKALE Network’s SKALE token (SKL) will be available for purchase through a 3-day Dutch auction on the platform on August 17th, 2020 at 12:00PM EST. Announced in February, the SKALE Network is the first project to launch with Activate, which has since accepted registrations to participate. For users verified on the platform, registrations for the auction are now open on https://activate.codefi.network/skale .

The SKALE token supports the highly anticipated SKALE Network, an open source elastic blockchain network designed specifically for scaling Ethereum by increasing transaction speeds, lowering transaction costs, and creating seamless workflows for end users and developers building applications on Ethereum. The SKALE Network’s mainnet has been live since June 30th. Each application using the SKALE Network gets its own chain for executing transactions at sub-second block times, with over 2,000 transactions-per-second. In addition to running full-state smart contracts, SKALE chains offer decentralized storage and can execute machine learning in smart contracts. Over 40 decentralized applications are currently building on SKALE, ranging from games to decentralized finance, to streaming audio and more. The combination of SKALE and Ethereum is a truly decentralized cloud that allows Web 3 applications to compete with Web 2 on both a cost and performance basis.

“There has been fantastic growth in decentralized applications and DeFi being built on Ethereum. ConsenSys Codefi is designed to enable the builders of our ecosystem with modular tools for commerce and finance, including the applied use of tokens. SKALE is a major step forward for the operating progress of the Ethereum economy, and we are thrilled to support the team,” said Lex Sokolin, Global Co-Head of ConsenSys Codefi. “Our goal has been to build a vertically integrated platform that enables a robust network launch and on-going use — where people can purchase and put their tokens to work as they’re intended. On Activate, after users purchase SKL tokens, they can start contributing to the security and scalability of the network through staking, starting from genesis,” said Collin Myers, Token Strategy Lead at ConsenSys Codefi. Users may be eligible to earn rewards through this activity.

Not only can users buy SKL tokens directly from SKALE Network on the Activate platform, but SKL token holders can stake SKL tokens in accordance with the SKALE Network’s protocol, and receive staking rewards directly from the network in return, without having to leave the application. Activate’s network dashboard makes it easy for users to decide which staking-as-a-service provider to choose to delegate their SKL tokens on the network. The SKL token is a hybrid-use token that participates in the network security mechanism, and is used as a means of payment for SKALE chains.

Activate uses the “Proof of Use “ distribution mechanism designed to get tokens to holders whose primary purpose is utilizing network tokens for their intended purpose. Proof of Use programmatically requires users who acquire tokens during a launch to actively “prove use” of their tokens on the network’s mainnet in specific use cases before they’re allowed to transfer or redeem them. In the case of SKALE, participants will be required by the protocol to delegate at least 50% of their purchased tokens for 90 days before being able to transfer them outside the network. This creates a measurable incentive mechanism aimed at minimizing speculative behavior from participants, while maximizing active contribution to the network. Proof of Use aligns with Codefi Activate’s Token Launch Standards which establish fair, accountable, and transparent practices.

About SKALE

SKALE is an elastic blockchain network that gives developers the ability to easily provision highly configurable fully decentralized chains that are instantly compatible with Ethereum. SKALE chains can execute sub-second block times, run up to 2,000 tps per chain, and run full-state smart contracts, support decentralized storage, execute Rollups, and machine learning in EVM. The SKALE Network is an open source project with many contributors including SKALE Labs, Inc. headquartered in San Francisco, CA. The SKALE Network’s supporters include Blockchange, ConsenSys Labs, Hashed, HashKey, Floodgate, Multicoin Capital, Recruit Holdings, Signia VP, and Winklevoss Capital. The SKALE Network is supported by top validators in the world including Blockware, ConsenSys, Certus.One, Chorus One, Dokia, Figment Networks, Hashed, Staked, StakewithUs, and Stake X, as well as key infrastructure player Bison Trails. For more information please visit www.skale.network , @SkaleNetwork on Twitter, and @skaleofficial on telegram.

About N.O.D.E. Foundation & Anstalt

The Network of Decentralized Economics (N.O.D.E.) Foundation is a non-profit entity based in Liechtenstein created to carry out the mission of supporting the SKALE Network open source project. The foundation is supported by the N.O.D.E. Anstalt, a subsidiary business arm of the Foundation. The Foundation is also supported by SKALE Labs, Inc. headquartered in San Francisco, CA. SKALE Labs provides support to the Network by contributing to the open source code, community growth, and other key efforts to facilitate the growth and adoption of the SKALE Network.

More on this topic

• Announcing the SKALE Network Token Launch on the Codefi Platform
• SKALE Staking and Rewards Primer

Originally published at https://consensys.net.

SKALE Token to Launch on Codefi Activate on August 17th, 2020 was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

View our security assessment RFP for Teku→

PegaSys has been a huge supporter of Ethereum 2.0 development since its early days. On the one hand, we have R&D teams pushing back the boundaries on several fronts. On the other, we have created one of the leading Ethereum 2.0 client implementations, Teku.

Teku is written in Java, with an Apache 2 license, and is a full implementation of the Eth2 Phase 0 specification, the Proof of Stake beacon chain. Once the beacon chain is launched, holders of ETH will be able to lock up stakes and participate in securing the chain by running validators such as Teku, for which they will receive in-protocol staking rewards.

The launch of the Eth2 beacon chain is now only a small number of months away, and we are working hard to ensure that Teku will be production-ready in good time. Teku has already successfully participated in all three public Eth2 multi-client testnets to date, Witti, Schlesi and Altona, alongside client implementations from other teams.

As part of our preparations for launch, we are now seeking an external security assessment of the Teku codebase. The security of all Eth2 clients is paramount: downtime will cause stakers to lose stake through penalties; loss of keys can cause a loss of stake through being slashed. Maximum uptime, maximum correctness, and a high degree of security are vital.

If your team has experience in reviewing large Java codebases, distributed peer-to-peer systems such as blockchains, advanced cryptographic constructs such as BLS signatures, and has a first-class security background, then we would warmly invite you to respond to our RFP for a security assessment of Teku. In-depth knowledge of Ethereum 2.0 is not required, but could be an advantage.

Please see our Request for Proposals document for all the details and information on how to reply to the RFP. The closing date for responses is 23:59 UTC on Monday 3rd August 2020.

We look forward to hearing from you!

More on this topic

• What Is Ethereum 2.0?
• What Is Proof of Stake?
• The Ethereum 2.0 Beacon Chain Explained

Originally published at https://consensys.net.

Teku Ethereum 2.0 Client: Request for Proposals was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.

ConsenSys Codefi just published its Q2 2020 Decentralized Finance Report, a summary and analysis of Ethereum’s DeFi ecosystem this past quarter. Some of the main topics covered in the report include:

• Overall DeFi data statistics, summaries, and visualizations.
• DeFi user behavior and network visualizations of the user relationships between protocols.
• COMP, Compound, and Yield Farming.
• BTC tokenized on Ethereum.
• Major security incidents and the rise of DeFi insurance.
• The performance of specific high-profile protocols, including Uniswap, Maker, and Compound.
• The state of stablecoins in Ethereum DeFi.
• A look towards DeFi in 2020 and beyond.

In this report, we identified the three most important DeFi events in Q2:

1. BTC Tokenized on Ethereum

What happened: In May, the amount of BTC on Ethereum (represented by tokenized BTC such as WBTC) surpassed the amount of BTC on the Lightning Network, Bitcoin’s layer 2 scaling network.

Why it matters: Cross-chain interoperability is anti-maximalist, but is the more likely future of blockchain. The teams enabling the tokenizing of BTC on Ethereum have been embracing this belief, and it is paying off. Also, Ethereum’s DeFi ecosystem has such a strong gravity that even BTC holders have been finding ways to use it.

2. COMP and Yield Farming

What happened: Compound released its governance token COMP in mid-June. Tokens have been rewarded daily to borrowers and lenders on Compound. The result has been that enterprising DeFi users have been maximizing their COMP yield (i.e. “yield farming”) by using DeFi mechanisms to unlock capital and then lending/borrowing on Compound.

Why it matters: Yield farming took the DeFi ecosystem by storm in the last two weeks of the quarter. Crucial metrics like ETH locked and daily active users soared after being fairly stagnant earlier in the quarter. However, data (discussed below) suggests the frenzy did not bring many new users into DeFi, demonstrating that DeFi’s innovation must be paired with education and UX before we see the DeFi community grow beyond its current borders.

3. Three Major Security Incidents

What happened: Uniswap, Lendf.me, and Bancor all had high-profile security incidents this quarter, collectively resulting in $26M USD stolen (most of which was returned, discussed in the report).

Why it matters: Security incidents are inevitable in emerging technology. The DeFi community continues to develop strategies to hedge against it, including: auditing services, security products, and insurance applications. All of this is benefited by the open source nature of DeFi, which allows third parties to monitor DeFi dapps, provide suggestions, and analyze attacks to help protect the entire community in the future.

Download the Q2 Ethereum DeFi Report

Originally published at https://consensys.net.

New Ethereum DeFi Report: The Rise of Wrapped Bitcoin, ETH Insurance, and Yield Farming was originally published in ConsenSys Media on Medium, where people are continuing the conversation by highlighting and responding to this story.