old Architecture

Architecture

Part 1: The Soup Market

I mentioned Bright Block Soup. Let's start a soup store together.

Some years ago, the Owner-Free Filesystem "OFFSystem" was conceptualized but ultimately failed to gain traction due to lack of participation. Additionally there was not enough data on the overall overhead of such a system. I'm going to explain the Owner Free Filesystem in the context of our block soup.

Why do you care to learn about this? This method of storing not only allows secure data to be held out in the open without security concerns, but it also essentially eliminates copyright concerns for node participants storing data within the network. One thing the world constantly needs more of is storage. Although providing storage to the network isn't required, doing so will be incentivized as we'll cover in a little bit.

Now, imagine you have a bowl of Alphabet Soup. In it are a bunch of jumbled letters that don't spell anything unless you do some work to arrange them. You can then re-arrange them into a new sentence and yet it's still the same soup. So what does that soup really spell out? Does the can you buy on the shelf inherently spell anything? If I dump a can out on the counter, it's not going to make a sentence once- let alone in a repeatable manner.

With that sort of thinking in mind, lets continue.

When we're packaging soup, we like to put it all in cans of the same size. But we do have different size cans like the family size and the standard 8 oz. Let's say we have a can of very special soup that we can dump out and it spells our message exactly. In order to keep the soup looking random, everything that gets put in must be randomized. Therefore we have a random soup can generator whose sole purpose is to have random cans with mixed alphabet messages ready to go for this. Say now we take the special can with our actual message and mix it using a mathematical operation on called an Exclusive OR (XOR). Each letter is affected in order by the added can of random soup and the resultant can looks totally random but in fact has all of the data you put in, though it is now dependent on the other can. This can looks random, but it is still heavily correlated to the original message. We then mix it with more cans in order to dilute the original flavor/message. We need to keep track of exactly which can types we used and they all must be different. Once the message has been mixed with enough random cans, we can safely put it out on the market and nobody will know what it actually says. We throw away the can of special, original soup.

In order to get your original can of soup back, you need to know which flavor of soups are needed and what order to put them in to be able to reconstruct your original message so you go and get a can with that recipe in it.

• Message M
• Random cans/flavors A B C
• Resultant can/flavor Z
• M ^ A ^ B ^ C = Z

now we throw out M and keep A, B, C and Z. These are different soup flavors.

To get M back, A ^ B ^ C ^ Z = M

Assuming your message is bigger than one can, we keep doing this over and over in order until we've covered the entire message.

Anyone is free to ask the store for a can of A, B, C, even Z. But unless you know the recipe for your original can, you can't get it back- especially if there are essentially unlimited flavors. Someone needs to go to the store with a billion flavors and know to ask for your four.

Now we have an open market where anyone can walk in, add soup flavors and request flavors with no questions asked. It's up to everyone to keep their own secret recipe safe.

Getting back to the network here, we can actually keep your recipe in another random can/block and put that into the network as well since it looks random. This makes long recipes (big files) easier to keep since you'll hopefully only need to keep track of a few cans types in order to keep your recipe. These essentially take the form of magnet links something like https://brightchain.net/blocks?recipe=A+B+C+Z

In order to identify the blocks, they will need an identifier. In BrightChain, the SHA256 of the block's full data packet is the id. There is no reason to store multiple identical blocks. *I suspect that there will be a link to a separate option block in order to deal with optional parameters.

For more information on the math, please check the OFFSystem wikipedia entry linked above. It also has links which discuss the overall efficiencies as measured empirically on the network when it was active.

Now, the Revolution Network has a way to store data out in the open, without encryption- although technically speaking this is a form of encryption native storage. At this point we're able to then start a user database.

Unlike BitClout which decided to store data off-chain due to the cost involved, The Revolution Network solves this with the massive distributed filesystem. Users will be encouraged to contribute disk resources and this will help their Valuation

---

On to Part 2: Authentication