4.0.1 Nebula¶

Changes since 3.3.0¶

This is the first major update of Solar Core since the launch of Mainnet.

Click on the following link to read a full summary of the 4.x release:
https://github.com/Solar-network/core/pull/97

Highlights¶

• Introduction of v3 transactions, featuring:
  • Combined Transfer and MultiPayment transactions
  • New Vote transaction type
  • New 'Temporary' and 'Permanent' 'Delegate Resignation' types
  • Optional Transaction Memos
• Improved Core Crypto web browser compatibility
• Tighter schema validation
• Near-instantaneous fork recovery
• CPU count-based service worker allocation
• Improved logging and errors descriptions

Requirements¶

Update instructions¶

Update your Mainnet node with the following command:

wget -4O- https://gist.githubusercontent.com/alessiodf/4faa98978ce547c1d8e96696f1d84e97/raw/cd9e7b83de0e5ac26a2e745d9452c9ed1d5c5195/update.sh | bash

v3 transaction changes¶

There are several key transaction changes to be aware of in Solar Core 4.x.

The 'memo'¶

All Solar transactions now contain a special 255-byte data field known as a 'Memo' and allows raw data, code, or plain text to be stored on the blockchain. The Memo is optional, public, and immutable.

This was previously known as the vendorField and was only available on certain transaction types.

v3 transfer¶

One of the most important changes is the introduction of the new Transfer transaction type.

Formerly, a single send transaction made use of v2-style Transfers (Type 0) whereas two or more sends required using a v2 MultiPayment transaction (Type 6).

Under Solar Core 4.x, these have been combined under the MultiPayment pattern and are now known simply as 'Transfer' (Type 6), removing the unnecessary requirement of two separate transaction types.

TypeScript Code Example:

const { Transactions, Managers, Utils } = require("@solar-network/crypto");
const { Connection } = require("@solar-network/client");

// Configure our API client
const client = new Connection("https://tapi.solar.org/api");

// Set the network configuration
Managers.configManager.setFromPreset("testnet");
Managers.configManager.setHeight(972604);

(async () => {
    // Step 1: Retrieve the incremental nonce of the sender wallet
    const senderWallet = await client.api("wallets").get("YOUR_SENDER_WALLET_ADDRESS");
    const senderNonce = Utils.BigNumber.make(senderWallet.body.data.nonce).plus(1);

    // Step 2: Create the transaction
    const transaction = Transactions.BuilderFactory.transfer()
        .nonce(senderNonce.toFixed())
        .memo("This is an example memo")
        .addTransfer("Address of Recipient Wallet 1", 1 * 1e8)
        .addTransfer("Address of Recipient Wallet 2", 1 * 1e8)
        .addTransfer("Address of Recipient Wallet 3", 1 * 1e8)
        .sign("this is a top secret passphrase");

    // Step 4: Broadcast the transaction
    const broadcastResponse = await client.api("transactions").create({ transactions: [transaction.build().toJson()] });

    // Step 5: Log the response
    console.log(JSON.stringify(broadcastResponse.body.data, null, 4))
})();

v3 Vote¶

Voting has undergone a significant conceptual change in Core 4.x. Previously, a wallet could vote for only one delegate at a time. Under the new scheme, a wallet can vote for up to 53 delegates in total as well as optionally customise the distribution of their vote weight.

For instance, the default behaviour of voting for three delegates where no custom distribution is specified would look as follows:

{
    ...
        "votes": {
            "cactus1549": 33.34,
            "gym": 33.33,
            "sl33p": 33.33
        }
    ...
}

When manually specifying vote weight distribution, natural sorting is still used; however, vote weight is prioritised while determining the list's order. For example:

{
    ...
        "votes": {
            "sl33p": 40.50,
            "cactus1549": 29.75,
            "gym": 29.75

        }
    ...
}

v3 Delegate Resignation types¶

Previously, v2-style Delegate Resignation was a permanent action. There was no way for a resigned delegate to reinstate their eligibility to receive votes and produce blocks. This was only useful in cases where a delegate no longer wanted to participate in network consensus.

Solar Core 4.x adds a new 'Temporary' resignation option where their resigned status may be 'Revoked' after at least two rounds (~106 blocks). This is useful when a delegate may only wish to resign for a short time without negatively impacting the network (e.g., missing blocks) and can be for a variety of reasons, from temporary node maintenance to personal/private matters.