owez / onft

Bespoke toolkit for Non-fungible token (NFT) technology

Bespoke toolkit for Non-fungible token (NFT) technology 🚀

What is Onft?

Instead of forcing a consensus algorithm or peer networking on you, Onft provides you with the tools to create a reliable and fast NFT system 👐

This allows you to focus on implementing the important stuff, as well as getting benefits such as automatic improvements and updates over this project's lifecycle, whilst still being fully standardized.

Example

use onft::Chain;

// create
let mut chain = Chain::default();
println!("Chain: {:?}", chain);

// add block
chain.push_data("Hello, world!").unwrap();
println!("Chain: {:?}", chain);

// verify
if let Ok(true) = chain.verify() {
    println!("Verified")
} else {
    eprintln!("Not verified")
}

Check the useful examples/ directory or the item-level documentation for more examples! 😊

Usage

Simply add the following to your Cargo.toml file:

[dependencies]
onft = "0.1.0-beta.2"

Licensing

This project is dual-licensed under both the MIT and Apache licenses, so feel free to use either at your discretion.

onft's Issues

Document serde support

Should be documented in the README.md as well as library-level documentation. A note should also be mentioned on blocks or chains about how the PROTO_VERSION byte will be attached

Move from RSA to ED25519

Due to the power of OpenSSL, hashes can be swapped out quite easily and should be done in the case of RSA vs ED25519 for message signatures primarily due to the length of a message signature.

To be future-proof levels of secure, RSA4096 should be used but this would create very large message signatures comparatively. The fix is simply to move to ED25519 signatures which have comparative security for less data cost due to the smaller size.

This will be done before the first 0.1.0 release and even before the 0.1.0-beta.1 one.

Don't hash data directly

The hash should be calculated from a hash of the data, so the full data does not need to be sent to verify a block, only:

• Previous hash
• Signature
• Data hash (used to be data)

First logo

A logo for the 0.1.0 release should be added to docs.rs and the readme to show some branding, the logo has already been made:

Add `Display` trait for all errors

Overdue, forgot it had a todo!() instead of any content.

Include byte conversion via serde

After the initial 0.1.0-beta.1 release but before the full 0.1.0 there should be a serde feature implemented allowing serialisation. This will also include a new serialized-only byte indicating the version, probably as 4 bits major, 4 bits minor which correspond to the crate version.

Lower res logo for `README.md` file

The logo is too heavy to load currently and takes a while, it can be scaled down without going over the top.

Switch SHA256 to BLAKE3 hash

Switching means greater speeds at the cost of having another library other then OpenSSL. At the time of issue opening, it was thought that switching OpenSSL to another library was needed, which is not the case.

Search for block hash & data hash

Should be able to search a chain for block and data hashes

Documentation run

Before initial release, all public items need to be documented

Fully document `BlockData` struct

Need to document BlockData more as it's lacking an example

More testing

Testing is a bit lax currently and could do with an overhaul