hypercube-lab / hypercube Goto Github PK

• Page allocation/management system. Notably that pages have their token balance auto-decremented and eventually expire
• Emulate gas by running a contract on a separate thread that gets killed if it runs for more than N milliseconds?

Add existing wallet API:

• get balance

• airdrop

• pay

• confirm transfer

• Read a Page given a PublicKey

• Check how long the Page has until it expires (at its the current token count)

• Allocate a new Page

• compile contract

• deploy contract (return PublicKey of the contract)

• call a contract

API documentation for web3-sol and the raw JSON RPC interface.

Miners should hash the TransactionProcessor state and transfer the data to the alpha node. In order to set an appropriate timeout, the alpha node should utilize that. That is the time when a batch is finished (which includes the wait time after the timeout ended and before the batch began to be fetched).

Revise the README file to provide a description of the Historian and how to utilize it.

This is referred to as the combine function in Section 4.2 of the Loom document.

Loom uses repr(C) structs and unions and does unsafe operations to get them into Rust. Instead, use all safe Rust. Compare and contrast.

• No VM, program is just an i386 .elf that gets loaded directly into the fullnode process. The .elf will have no external deps (no plt, pic, rx) and we'll write a custom loader that works on Windows, Linux, macOS.

• .so needs to be signed (to identify the author's public key only ?) and verified as being unmodified before loading.

• Source code is any language that can produce a compatible .elf (potentially just C since that'll likely be easiest to get toolchain to output the right .elf but could also a "safe" subset of Rust (no unsafe, external crates, spawn)

• Hosted server service that accepts signed source code, compiles it into an .rexx, and "installs" it on the testnet. Contract ID (publickey?) provided back to the submitter

• Produce an RFC that discusses how programs are loaded on-chain

The conceptual designs for IELE and HyperCube implement smart contracts from diametrically opposed perspectives. Everything has a gas price assigned to it in IELE, which is a generic Turing-complete programming language. An alternative to this is a spending plan, which is a very basic language in which every branch spends all of the bonded tokens and an implementation that does not need any memory allocations. In order to map spending plans to IELE, we'd need to consider a subset of stack-allocated programs where the gas price is extremely tiny and can be estimated in advance of the expenditure plan.

Create a data structure that contains all of the account balances.

Key Takeaways

• High performance bytecode designed for fast verification and compilation to native code
• Memory management that’s designed for fast analysis of data dependencies
• Execution of smart contracts that is parallelizable in as many cores as the system can provide

I will use all-contributor bots to add contributors to this project

Monitor a network address and pass communications to the accounting department if necessary

• Used by our reference/demo web interface. But can also be used by custom DApps that want to use XPZ
• Javascript wrapper around the JSON RPC Node Service directly

At the moment, there is nothing that prevents a validator from accepting two batches of transactions and processing them in parallel mode. It's conceivable that the debits from the second batch will cause an account to overdraw before the credits from the first batch are credited to the account. If this were to happen, the validator would erroneously vote a legal block as an invalid block, which would have no effect on anyone's account, but would result in a needless rollback and the leader's bond being slashed without justification.

Due to the fact that transactions spanning tick borders are guaranteed to be sequentially consistent, we will most likely only need to submit a Tick to the historian immediately after processing the parallel batch of transactions.

https://github.com/qmonnet/rbpf

• UI for submitting a program to the system for building and installation on a particular testnet
• Web-based editor, ideally something with Rust syntax highlighting.
• SDK Documentation. Potentially just some medium articles with examples as a v0.1
• Primitive user keypair management. All browser based. Leverage ideas and code behind https://metamask.io/ when possible
• Memory page explorer. View the current contents of any memory page allocated in the network, who owns it, and the current token count.

The accountant stub routines are all contained inside a single block. That's OK for the time being, but we'll want to switch to all async calls as soon as possible. For now, wrapping each return value in a future and updating the callers (most of whom are in client-demo.rs) to utilize them is a good first step toward getting there.

See https://crates.io/crates/futures for further information.

It's worth noting that the tokio framework reexports the same future library, which means that if we utilize it as our async runtime, the move will be seamless.

Each contract has its own Lua stack.
To advance over several events, use coroutines.

Consider if clients and verifiers need access to the whole log. At the moment, the accountant gets fresh log entries by listening to a sync channel that is controlled by the historian. There is no serialization of such entries, and they do not travel throughout the network.

This ticket's implementation may be done by adding historian stub and a matching historian skel that listens on the internal channel to the database. Another possibility is that we will need a generic "switchboard operator" that simply translates network protocols to our deserialized, well-typed channels.

• Should we do L0 verification of blocks without context?

• We can calculate deltas

• Some event data doesn’t coalesce well (i.e. Witness events)

• But two timestamps do.

• Should events within a single entry be processed in parallel?

• How to identify when order affects output?

• Example: Race(PayAfter(date, to), CancelOnSig(from))

• Applying a credit first could allow a debit to proceed

• For conflict resolution, should we look to event order within the entry?

• When leader creates the entry, should it order ambiguous events or discard one? Discard all?

• Should events across entries (all events in one block) be processed in parallel?

• For conflict-resolution, entry order within the block unambiguously determines order.

• First event seen gets added to the entry. Any event that can't be processed in parallel gets pushed back and considered in the following entry.

• Calculating only deltas without any context sounds appealing. Applying the delta can be a separate validation step. Note this is only applicable to validators, where you have the option to reject an entire block. The leader, on the other hand, needs to reject bad transactions individually.

• No intent to parallelize event processing across entries. Note that may massively reduce the opportunity for parallelism. Need to run the numbers on that.

• Takeaway: maximize transaction throughput.

Running the whole testnet within a single OS process will expose race conditions to the Rust compiler. Is it doable?

• CLI is mostly expected to be used for tests and automation. Essentially all functionality provided by the web-interface should also be exposed at the CLI level
• Talks to the JSON RPC Node Service directly