casper-network / roadmap Goto Github PK

Refactoring of JS SDK with reimplemented CLValue

• design archival node

Purpose

Background

• Enterprise blockchain implementations are typically private networks of a small number of nodes that are managed either in a cloud provider or bare metal, depending on the organization’s internal IT compliance requirements.

• Enterprises are choosing private networks for the same reasons they started with private cloud - privacy, comfort and control. For the foreseeable future, they will use private instances for their purpose.

• A private blockchain fully under the control of its' owner doesn’t provide the security guarantees that come with the public network. Casper also supports the social consensus feature that does enable global state modification in the event of an emergency.

Business Goals:

Provide a mechanism that draws security from the public protocol into private blockchains.
Drive utilization of the public chain in private blockchain deployments.

Features, Functionality & Behavior

• Block hashes of the private chain are sent to the public blockchain in a transaction.
• Frequency of block hashes can be configured - ex: register every 10th block
• A configuration file for the product specifies the frequency of block registrations.
• Configuration file also contains a set of node endpoints to send transactions
• Wallet address and pem file for key to sign transactions
• Block hashes that have been registered to the public Casper network are matched up with the transaction data from the public protocol - so proofs can be provided that the blocks have not been modified.
• Application runs on a node and sends the block hashes as new blocks are finalized by the network.

• Include chainspec.toml version in handshake
• Limit deploy size to 1 MB
• Limit message size in chainspec.toml
• Deduplicate block validity criteria update
• Recursive query protection
• Additional costs for addBid (bonding and delegating will cost 3 CSPRs)

1.1.2

• [bug fix] canceled proposals after a restart, due to the block proposer not responding

Required node endpoints

1. GET /peers – returns IPs of peers that the node knows of. Light clients need to be able to find new nodes they can ask for data.
2. GET /blocks/signatures/{blockhash} – returns collection of signatures for the block identifiable by the blockhash. Light clients need to verify that the block headers were signed by enough validators.
3. GET /blocks/headers/switchblocks?era_id={eraid} – returns a header of a switch block that era. Light client uses that to synchronize by eras, instead of every block individually.
4. GET /blocks/headers?height={height} – returns a block header of the block identifiable by the height.
5. GET /blocks/headers?hash={hash} – returns a block header of the block identifiable by the blockhash

Run the chain with a lower minimum exponent (32s).

Currently, nodes must download every block to join the network. Starting from genesis, the node executes each deploy in each block. This process continues until the node has arrived at the current state of the blockchain.

Fast syncing does not start at genesis. Instead, the node starts by downloading the underlying database of the blockchain. The node downloads the database in a secure and distributed fashion. The process is akin to BitTorrent. The node tries to download as recent a copy of the database as possible. After that, it executes blocks to arrive at the current state of the blockchain.

• Move remaining ee types to casper-types

Parity stopped using wasmi - instead, they're using linear compiler called wasm time.

• Spike: complete the investigation of safety and realistic performance of wasm-time

The change is available for internal/external users in cargo-casper.
Tests should be amended to check for costs that are being derived via chainspec.

• [Design]: Come up with the spec on host-side enforced taxonomy.
  • Modules for host-side functions.
• [Story]: Contract WASM validation.
• [Spike]: Explore DAO proposal voting schemes for the upgradeable smart contracts.
  • Support the block height on the Contract API to be able to set the boundaries for voting.
• [Story][Tech debt]: change bad names in the contract space.
• [Design][Story]: Support for the Factory pattern. Sharpen the requirement, is Factory sufficient or we need to provide more.
• [Story]: Add whitelist/[explore]blacklist powered "Identity" variant to EntryPointAccess and enforce host side
  • Blacklisting should inspect the whole callstack. Whitelisting should inspect the immediate caller.
  • Mark Greenslade will prepare a case study for the blacklist scenario.
• [Story]: Entrypoint identification of the caller.
• [Story]: Ability to bind wasm against its source code via L1&L2 tooling

Exclude inactive validators from proposing blocks:

casper-network/casper-node#1404
casper-network/ceps#43
https://casperlabs.atlassian.net/browse/HWY-289
https://casperlabs.atlassian.net/browse/NDRS-1158

Remove the acceptable_drift; stop syncing when we are in the current era:

casper-network/casper-node#1440
casper-network/casper-node#1435

Port synchronizer improvements from 1.2.0 to dev:

casper-network/casper-node#1402
https://casperlabs.atlassian.net/browse/HWY-292
https://casperlabs.atlassian.net/browse/HWY-293
https://casperlabs.atlassian.net/browse/HWY-294
https://casperlabs.atlassian.net/browse/NDRS-1237

Reject transactions that are invalid. Do not propose transactions that cannot be paid for.

Summary

A user-facing application to monitor the state of the network and the on-chain assets.

Details

Monitor staked assets and validators.
Trigger notifications in case the validator has stopped responding.
Display the information about the state of the assets (delegating/undelegating with ETAs)
Ability to stake (?)

UI/UX

A website with Signer integration.

What is a Light client?

(from Tendermint specs)

A light client is a lightweight (hence the name) alternative to a full node. Full nodes often are resource-heavy because they execute transactions and verify results (and do a lot of other stuff). Light clients, on the opposite, have low resource requirements since they only verify results (without executing transactions). Full nodes often store a lot of data (blocks, transaction results, etc.). Light clients only store a few latest headers.
A light client is a client, which connects to a full node, requests new block headers, and verifies that those headers can be trusted.

Light clients are assumed to be initialized once from a trusted source with a trusted header and validator set. The light client protocol allows a client to then securely update its trusted state by requesting and verifying a minimal set of data from a network of full nodes (at least one of which is correct).

source

(from Solana docs)

A ‘light client’ is a cluster participant that does not itself run a validator. This light client would provide a level of security greater than trusting a remote validator, without requiring the light client to spend a lot of resources verifying the ledger.

Rather than providing transaction signatures directly to a light client, the validator instead generates a Merkle Proof from the transaction of interest to the root of a Merkle Tree of all transactions in the including block. This Merkle Root is stored in a ledger entry which is voted on by validators, providing it consensus legitimacy.

source

Requests originating from @zie1ony .

CC @MParlikar @Fraser999 @EdHastingsCasperLabs @mpapierski

Some scenarios benefit from a malicious node exhibiting one or more behaviors that the network should be resilient against. We currently lack a creditable strategy to create and support such malicious nodes. Designing and maintaining such nodes incurs a significant cost over time.

Currently the full Highway protocol state of unbonding_delay - auction_delay (= 6 in mainnet) past eras is kept in memory. This allows us to detect equivocations even if someone sends a very belated message, and it allows joining nodes to catch up using Highway itself.

We can save memory by keeping only the current era:

• Equivocations are still detected as long as some nodes are in that era. If none are, the equivocation is inconsequential anyway.
• Nodes that are lagging behind can still catch up if we send them the old era's finalized, executed, fully signed blocks. No need to download the Highway protocol state of a concluded era.

Original idea was to restructure the existing deploy, however, we will keep existing deploy type and create a new "transaction" type. We will deprecate the existing deploy in 2.0, remove the deprecated deploy in 3.0

Requirements:
New type: enum transactionKind which contains a set of enums (Native, NativeTransaction. This new type will then be the union of these new enums:
New Enums: Native, Userland, PricingMode
-- native: enum NativeTransaction (MintTransfer(RunTimeArgs), Auction(enum AuctionTransaction(AddBid(RunTimeArgs))) ReservationIRunTimeArgs)). -- native contracts for the chain, was session
-- Userland: enum UserlandTransaction( Noop, Closed??-- like a pure function i.e. can't call a contract, Installers/Upgraders -- called out so we can allow more space (via module_bytes), DirectCall , standard
-- standard variant is a new size of module bytes that can be much smaller than installers/upgraders.
-- install/upgrade variant is the current module byte size definition for installers/upgraders (large)
-- no more stored sessions
-- DirectCall: StoredContract, ContractByName, ContractByHash // all 4 types.... all 4 channelled in one channel
-- PricingMode: (enum slot, price, ??). -- was gas_price
deploys that do not follow a supported gas_model will not be accepted.
No dependencies field
session changing to new enum
channels defined in chainspec: channel_name - map "kind" to "lane"; types and number per block (allows us to manage block sizes, e.g. how many total installerupgraders, etc)
// prepaid reservations would be the first channel to draw transactions from; calls new native escrow procedure

Reorganize any other existing ExecutableDeployItem fields into the appropriate enum or in the transaction.

• Purge expired deploys (deploys that expired before execution)
  • Consider running on upgrade (lazily) Joe Sachershould indicate when is best to purge.
    • casper-network/casper-node#2155 Purge expired
    • casper-network/casper-node#2149 …and emit event

A separate SSE for contract log level events only. When a contract executes, if it has a logging event, this is emitted to the event stream.

Server and the client enhancements.

• Version separately

Ability to rebuild Global State from the Event Stream.

End to end dapp with web UI.

Features:

• secured signing of the documents,
• decentralized, non-custodial certification- ?,
• storing security-critical data on-chain supported by ipfs,
• chain monitoring.

Outcome:

• online service - web page
• REST/graphql API
• nodejs backend
• smart contracts deployed to the private network