Design philosophy
The NANAS design philosophy is the ORD design philosophy. We wanted to make a protocol that achieved the same design principles at the core of the original Runes protocol which we admire greatly. We only differ to ORD on one key factor:
Simplicity
Adding abstraction layers like Segregated witness data (which Runes uses for commitments) make the protocol hard to understand and increase the barrier to entry for new users. ORD does a good job at abstracting this complexity with the official ORD node, but our philosophy is to abstract this complexity at a protocol level. Failure to do so has had a direct negative impact on attracting new developers to Runes, we wanted to avoid this with Nanas.
Essentially, the protocol should work on all btc nodes (SEGWIT and pre-SEGWIT) and at a protocol fundamental level be easy to grasp. Layers of complexity should be avoided.
This goes beyond Nanas and into everything we do at Nanalabs, from the protocol to our tools - they should all be simple to use. Simplicity drives growth, because simplicity gets the masses to adopt our technology. This is especially important when the value a fungible asset protocol is directly tied to the amount of indexers that agree on its ledger history and the amount of users that trust said ledger.
TLDR: NETWORK VALUE = ADOPTION. ADOPTION = SIMPLICITY.
Other than this, our values align completely with Ord's values
We wanted to make a protocol that builds and adds value to the Bitcoin network, rather than one that hurts it. We know and understand that adding a programmable layer to Runes is a task that must be done with a lot of due diligence, and throughout these docs and the pages that follow you will see this being exercised.
To continue, i'll list out a few other values we share with Ord, our stance on them, and how Nanas enforces them:
Fairness & MEV
EVM chains are plagued by MEV (Miner extracted value), and adding this to Bitcoin would be irresponsible and hurt the network. That said, we do not believe that this should be a responsibility of the protocol itself, rather the users and the programmable layers (programs) built using Nanas.
Example:
Consider a "swap" program. Adding a slippage setting (like Uniswap) prevents MEV (or atleast a lot of it) by outright rejecting a swap if a sandwich attack is attempted. This responsibility is being exercised by the program layer, not the protocol.
This could further be improved by adding a "commitment" step. An example of this could be as follows
User wants to swap NANA-A for NANA-B
User creates a commitment on the contract expressing this swap intent. The intent has a SHA256 hash attached, concatenated with a salt only the user knows.
When the block is mined, the commitment becomes valid. The user can then use this commitment in any of the next 6 blocks to create a swap from NANA-A to NANA-B, while in said transaction including the salt used.
Attacker sees transaction making the swap, but cannot frontrun the tx because they themselves need a commitment as well. They also also cannot pre emptively make a commitment because since only the hash is made public - no details about what the swap may be are made available to the sandwicher (making a lot of commitments preemptively and choosing one later would remain ineffective, because the slippage used by user is also private in the commitment). They also can't accumulate commitments on popular pools, as they become invalid after 6 blocks.
While this is just a quick example - all contracts developed by Nanas would follow this philosophy (and initially these are the only ones that would be available to indexers, more on this in #persistance-and-consitency)
-> Any programs created that introduce MEV to Bitcoin would naturally not be adopted by people using the Nanas protocol, because doing so indirectly hurts them. Nanas lives on bitcoin, hurting bitcoin hurts Nanas.
Persistence and Consistency
This philosophy relies on one specific rule: Indexers must always agree on a state for the protocol
Introducing a programmable layer while processing a Banana (see Nanas) naturally produces the potential for variability within this state if implemented incorrectly. This is due to the fact that the specific methods being called while executing the program might error or be dropped by some indexers, or accepted by others
This absolutely cannot happen
If such a scenario were to occur a hard fork would be created between indexers, which would be very bad for the protocol. A complete overview of this issue and our solution can be found here:
Upgradability
At a protocol level it is important that Nanas allows for upgradability incase something fundamental about the Bitcoin network changes causing Bananas to break. The term coined for this hypothetical event is called Banana dysfunction (BD).
If BD were to occur (for example, the block size limit increases to allow for more than 65535 transactions inside a block, breaking u16 indicies for block transactions) - then the differentiation will be made at the indexer level, with two new banana decoders being used by the indexer to define the upgrade.
Example:
Theres a Bitcoin hard fork that increases the block size limit to allow for more than 65535 transactions inside a block.
Banana decoder 1 (BDE1): Indexes transactions with 16 bit unsigned integers
Banana decoder 2 (BDE2): Indexes transactions with 32 bit unsigned integers
Hardfork happens at block x. Before block x, only BDE1 needed to be used to decode OP_RETURNS made on the protocol. After block x:
Indexer uses BDE1 for blocks ( < block x )
Indexer uses BDE2 for blocks ( > block x)
By allowing the indexer to seamlessly switch between banana decoders, the protocol becomes resistnent to changes on the Bitcoin network.
Last updated
