pixelspark / catena Goto Github PK

Post to other peers so they don't have to be mined at the peer that originated them. Needs a check to find out whether a transaction is already on the chain or not.

Only those transactions that are not on the new chain, obviously.

The reason Catena currently doesn't compile on Linux is the WebSocket client library used (Starscream) which relies on CFNetwork. This should be replaced with something that uses (for instance) BlueSocket.

Perhaps with a triggers table that has on, condition (see also #11) and statement columns (and perhaps also a way to run the trigger as the invoker or as the definer).

Syntax would be 'CREATE TRIGGER' still.

See e.g. https://docs.syncthing.net/specs/relay-v1.html

As is also done by Ethereum (see https://github.com/ethereum/wiki/wiki/enode-url-format).

Peers without username can only be passive peers and may not appear in advertised peer lists.

A node should print its node ID and URL (as far as it knows its own IP) when starting.

Support at least:

• SHA256(str)
• VERIFY(signature, publicKey)
• LOWER
• UPPER
• LENGTH

--init-only should create the peer database and seed the chain, but nothing else. (Useful for Docker images)

Enforce transaction count and block size limits in Miner.

Needs a proper Linux WebSocket Client (Starscream relies on CFNetwork and that is not available on Linux)

Instead of PoW, allow a select set of keys to sign blocks. The genesis block decides on the mechanism used for signing blocks.

The list of keys that are allowed to sign blocks should be stored in a special table.

See also ethereum/EIPs#225

Keep a 'grants' table in the database that validates mutations.

Add a command line switch to disable grant validation for databases that do not need it.

Currently, a node can choose whether to 'replay' SQL transactions on top of the database engine, and select only those tables that it is interested in. The query history however needs to be stored by all nodes for all tables (nodes could throw away blocks after a certain amount of time has passed, but that would make it impossible for new nodes to download the full blockchain from block 0).

It would be preferable if SQL transactions could be split into 'side chains', where each node would only 'follow' the side chains of its interest (and discard the rest).

• A sidechain is an independent block chain with their own numbering and sidechain genesis (which identifies a particular sidechain)
• Root chain blocks contain only the hashes of newly mined blocks (if they are accepted). For a miner to determine which sideblocks are acceptable, it only needs to check the last block in the sidechain (is index successive) and maintain state (what is the sidechain difficulty?).
• The root chain should contain an incentive for mining a side chain block ('credits'?).

Starting a sidechain would be akin to creating a new database. The root chain may also handle payments and dropping of sidechains (either upon request, or when a certain time has exceeded).

Nodes mining a sidechain block should perhaps be required to 'prove' they also still have all history blocks (perhaps by requiring a deterministically randomly chosen history block to be included in the signature hash?).

Things to figure out:

• How to incentivize miners to both mine the root chain as well as the side chains?
  • Make root blocks only mineable if a miner has provably done N sidechain work (sum of sidechain difficulty * blocks mined since a certain root block)?
• Difficulty levels of the side/root chain?
• Should there be a single difficulty level for all sidechains, or individual difficulty levels?
• Difficulty level for a new sidechain? (genesis requirement)
• How to ensure that nodes actually keep the blocks in side chains available for download? Require at least the miners to do so?

Like what Bitcoin does: https://en.bitcoin.it/wiki/Block_timestamp

Expose to queries as $approximateTime.

Add a column to the grant table that (optionally) contains an expression that needs to evaluate to true in order for the grant to be available. The user column also still exists, but may be set to NULL to always match:

Examples:

• kind=insert, user=NULL, condition=$invoker=X'somehash',table=sometable: equivalent to user=someHash
• kind=create, user=NULL, condition=$invoker=$miner, table=NULL: allows miners to create a table
• kind=insert, user=x, condition=$timestamp < y, table=z: allows inserts to a table only before a certain date/time (approximate)

When index << current index and/or timestamp << current time

Block nonce and height are currently defined as UInt64, but can JSON carry this? If so, it appears the Linux builds fail to serialize/deserialize.

See e.g.

Add a 'users' table that maintains a counter, incremented for each transaction invoked by a public key. Transactions are only allowed when their count = previous_count + 1

Appears to be an issue with deserializing JSON (which seems to be okay...). Might be an issue with my setup (Ubuntu 16.04 with Swift 3.1).

Options to investigate:

• STUN
• TURN
• ICE
• uPnP
• NAT-PMP
• TCP/UDP hole punching?

Persist a peer database

When counter > current counter (but below a certain threshold), remember the transaction in the hope that the transactions in between will be fulfilled shortly.

Do not execute queries except those required for validation (e.g. process only grants).

What Bitcoin does against sybil attacks:

Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.

It should be possible to disable this for private/testing deployments.

Using Bonjour?

Make seed.catena.pixelspark.nl an A record that points to (non-replaying) catena nodes.

Do not advertise peers discovered through DNS seeds to other peers.

Add reply type to 'query' request indicating the the peer does not maintain an index ("passive" action type). Change peer state to .passive and do not query anymore (but do send updates for blocks/txes).

Do not maintain a 'blocks' array in Ledger; instead, use the persisted storage (now SQLHistory) to find blocks.

Do not (tryo to) connect to all peers ever received, but select based on last seen and latency.

Block should be <10MB, transaction <100kB?

If a node receives a block from a peer that it hasn't seen before and it can append it to its chain, it should forward it to all other peers (except to the peer that sent it).

These lead to errors on Linux - serialize as NSNumber(value: x) instead.

In the grants table, add an expression column that optionally contains an expression that restricts any action performed using the grant, so you can:

• Grant a user to only DELETE/UPDATE rows that adhere to a condition (when the grant is used to perform a DELETE/UPDATE query, the restricting expression should be ANDed to the original WHERE statement)
• Grant a user the right to only INSERT rows with certain values
• Grant a user to only CREATE tables with a certain name

The expression should be able to contain special variables to check certain things, e.g.:

• $invoker: the public key of the user invoking the transaction. A grant with expression "$invoker=owner" would only allow modifications to rows that have the public key of the invoker in the 'owner' column. This could be made more complex, e.g. (CASE WHEN $owner=x THEN ... WHEN $owner=y THEN ... ELSE 0 END).
• $index: the index of the block this transaction is part of (useful for allowing transactions only after a certain amount of time)

Database should contain a table that holds feature flags (e.g. which signing/key algorithms are used). The table should be created in block 1.

Some ideas: have a $miner variable that contains the public address of a miner, then use that to send extra quota (through grants) using a query stored in 'flags' executed as first query for each block.

Some ideas:

• Per-table (or per-row?) expiry date that can be 'topped up' using credits (for which the coins are generated by mining)

• Evicting expired CREATE/INSERT/UPDATE queries from the chain completely (requires merkle trees)

Currency system for database privileges, e.g. grants with a quotum on the maximum number of times they are used, and/or the number of bytes stored, etc.

After a certain amount of non-response, reset the peer state to .new and close connections.

Currently, difficulty is fixed at a low value. This could be managed using a 'flags' table that holds the difficulty and/or contains an expression to calculate the difficulty (based on $index, $averageBlockTime, or something like that).

See also #32

Strace shows:

setsockopt(15, SOL_SOCKET, SO_REUSEPORT, [1], 4) = -1 ENOPROTOOPT (Protocol not available)

Solution is probably to not use SO_REUSEPORT.

This allows to implement encryption and authentication between nodes in the future.

Specifically detail size of fields, endianness, etc.