rutile-io/rutile

Fee-less decentralised applications ⛓

Rutile is a fee-less decentralized application platform. You can store files, create smart contracts and transfer tokens. Rutile is Ethereum compatible, it works with your current wallets. Just adjust the provider to localhost:8545

Rutile is currently in development but is actively worked on.

Running Rutile

Rutile is developed in TypeScript and requires node.js.

npm install

For testing the node server:

npm run start:node

You can use wallets like Metamask and use the custom provider (localhost:8545) to transfer value around.

Features of Rutile:

• Create and run smart contracts (using WebAssembly) & be compatible with Ethereum smart contracts
• RUT Token transfer
• Store files in the Rutile network using IPFS
• Re-use your Ethereum private keys & addresses in Rutile

More info

• Rutile Virtual Machine

Currently testing is done in src/js/index.ts.

Contributing to Rutile

For contributing create a PR or contact Franklin Waller: [email protected]

For more information see: https://rutile.io

If you want to support the project by donating to Rutile you can use the address: 0x42b904bcA15eb96488912456C17475ce33e0d3cF

rutile's Issues

Add support for JavaScript VM

Adding a JavaScript VM makes it easier for developers to develop their application with a language they are familiar with.

IPFS integration (non-incentivized)

Use IPFS for storing files and WASM smart contracts. For now, this should be non-incentivized. The incentivized issue will be created later

Hash mismatch with ethers.js

When signing and sending a transaction with Ethers it results in a hash error mismatch

Internal smart contract for incentivising IPFS

Create a smart contract that incentives nodes to store files.

Allow smart contracts to run on the DAG

Currently, it's disabled because DAG transactions cannot determine one state for a smart contract. Use milestones to guide these smart contracts

Use transactions nonces to detect double spends

A transaction should include the nonce that represents the number of transactions is sent. This way we can quickly find transactions that are double-spending and let the network choose which transaction is deemed valid.

Snapshot the current balance state

Rutile should regularly create snapshots of balances/Merkle roots. This way we don't have to walk the complete DAG for validating transactions

Create receipts for transactions

All transactions that were executed should return a receipt that includes proof that the transaction happened.

Validate a deployment before creating a address

Validate the binary that is given before deploying the address

Support 128bit & 256bit numbers

To keep Ethereum supported we also need to support up to 256bit numbers. Currently, in WASM big numbers are not supported. So we either need an extra module to handle these values (written in WASM). Or need to drop support for 256bit numbers altogether.

Make Proof of Work difficulty dynamic

We want to make the Proof of Work that is being done on transactions dynamic. The reason is to prevent spam. It should be done in a way that punishes bad actors from spamming the network while not bothering legitimate users.

Create milestone transactions

Create milestone transactions that give finality to submitted transactions.

First, the "heavy" version will be created. This will continuously calculate the newest milestone chain that is forming. It will talk to different nodes to know what kind of chain they calculated. If the path a node has chosen is different from its own perception it should update accordingly. This will eventually spread around all nodes in the network gaining a consensus for which milestone chain is the valid one.

The second implementation will be using indexes to figure out the best path. Transactions are submitting their transaction with the index of the transaction that has been done on the address. This will create an order for the address. Of course eventually, for busy addresses, this will split in multiple indexes. In this case, we should use the first implementation to figure out which transaction will come first. For not so busy addresses (Or private addresses) the indexes will not be busy and do not need additional consensus checking by the network.

Validate transaction balances

Reverse walk the DAG to make sure a transaction tip is spendable before selecting it. If a false transaction is found remove it from the database so that all transactions that approve the false transaction automatically gets caught up in limbo.

Replace WRTC with libp2p

The WRTC requires a lot of manual configuring. Using Libp2p we can handoff a lot of boilerplate stuff.

Blocks should include the parent it continues on

When a block wants to execute the code for address x, it needs to attach itself to a parent that last executed the same code. This way there is a logical order which state is continued on.

If a block has two forks of states the milestone will resolve the state transition and will act as a wave point.

Look into the possibility of replacing the VM with the PlayOS Kernel

Is your feature request related to a problem? Please describe.
There are two VM's, one for Rutile and one for PlayOS. This is fragmented. Both the Rutile VM and PlayOS VM are depending on WASI for their interactions.

Describe the solution you'd like
Use the PlayOS Kernel as the main VM for handling WASI interactions. We could simply write a provider that allows for storing the files inside a Merkle tree where we do path->value.