messages: add a resolver method

Imagine having a message

const message = new BlockMessage({transactions: [hash]})

Without resolver

message.decode() // {transactions: [hash]}

With resolver

const resolver = (propertyKey, value) => propertyKey === 'transactions' &&  peernet.get(value)
message.decode(resolver) // {transactions: [{from, to}]}

or

const resolver = (propertyKey, value) => propertyKey === 'transactions' && fs.readfile(value)
message.decode(resolver) // {transactions: [{from, to}]}

chain & wallet: encrypt the wallet before switching to mainnet

chain: machine execution should only block thread when the same user interacts with the same contract (or other interacting contract)

To keep transactions in order, these are async/awaited, blocks the execution for other users, while only necessary when a user interacts with the same contract in a block

chain: statestore needs to include accounts or drop accounts?

Whenever a node connects it will try to update from the state store, meaning accounts should be in the state also or empty nodes will fail getting the account nonce

Solutions

drop accounts (easy but means no easy way to check for total transfers)
rewrite accounts so that when a state is saved we include the accounts in state and clear the local accountsstore.

last thing before prelaunch (pinky promise) (LIP1)

The problem

Transactions are included in the block, which requires nodes to load those blocks before they can access the transaction count, hashes etc

currently they look like

block.transactions // [{
  hash,
  from,
  to,
  params,
  ...
}]

// load and loop trough all blocks
for (const block of loadedBlocks)  {
  for (const tx of block.transactions) {
    transactionPoolStore.has(tx.hash)
  }
}

this makes things hard/cpu expensive to keep nodes in sync because transactionPool keeps including transactions that are processed already.
meaning we would need to loop trough all blocks and it's transactions.
We could just set a time/blockamount limit on it ofc, but while this would work to reduce the amount of processing this would also result in transactions getting lost (imagine a power outage where a node is disconnected for 10 min and in that time the timeout experises ...)

Solution

Blocks should just hold the transaction hashes while transactions should get their own storage.
This way we can loop trough all transactions in the pool and just check if it

exists already locally
exists already on another node
get the transaction data directly (vs looping trough blocks and searching for it)

how it would look

block.transactions // [transationhash]
// existing hash
await transactionPoolStore.has(transactionhash)

// getting tx data
await transactionStore.get(transactionhash)

performance improvement

x10

TODO

edits

17/11/2022 - remove proxies & proxy manager, when stateStore is implemented, proxies are not needed.

chain: add in serviceworker (browser)

seperate thread
background sync
etc

chain: add validator selection & timeout

Let validators vote who to handle the incoming transactions

validators get rewarded only when voted for
timeout whenever a block takes more then 10 seconds to be validated and revote

chain: Prepare for testnet (actually sign transactions) & improve TPS

Current TPS 1000TX/1s (1 validator)

include transactions in the block instead of making a request for each transaction
sign transactions
seperate the networks storage

The thing todo

Introduce a simple faucet (for now)

Why?

Makes life easier for testers (and me) trying to get some LFC coins to checkout the test platform.

How?

A contract should control this, whenever a request happens it checks if the user has less then the max amount they can own to get the coins (let's say 500)

figure out if major worthy
bump minor or major

leofcoin / monorepo Goto Github PK

monorepo's Issues