Aeternity with a secondary linked chain

Protocol Features & Updates
1

Ok this is something I don’t understand at all. So I warn you guys, I may be talking a lot of non-sense.

So, I see the blockchain stores permanent data, what about volatile data?

---- sigh, I hear myself and just thinking about this is… so crazy —
What if I wanted to place something like a secondary blockchain that stored data with a TTL, and the way to access this data was via an endpoint. The sort of data stored in this secondary blockchain would be either completely decrypted (and/or signed), symetrically encrypted (and/or signed), public key encrypted (and/or signed) or private key encrypted.

I don’t know the details but the idea is that you pay on the main chain to something (oracle, contract, idk!) and then you get access to the secondary blockchain to store some information.

So say you want to open yani.chain, you use the AEbrowser, type the address, click on website, it gets the resource you need to process to get the list of files and the entry point. you get the list of nodes in the secondary blockchain, you connect to a few of thems and request the list of data, you then get the files from the proper endpoints and load all the information. Since the blockchain already contains at least a bunch of connected nodes the website is decentralized, since the name is resolved in the main blockchain the name resolver is decentralized.

Ok, this idea is super crazy, not matured and kinda weird, but this is what i have been thinking of since the name AENS popped up. I have been thinking what is preventing us from using some sort of storage system? from making a set of nodes that store data for a limited time? and get paid for that data? Can’t I just make a node that stores data and space and put a price on it in AE and make it so people could use the space witout having to worry about where it is physically located?

I am basically trying to find uses for the blockchain so we can make people holding AE or providing a node to make money from the service.

What do you think @philipp.chain @dimitar.chain @hanssv.chain ?

– Note –
You are not required to answer technically to this question, you can very well expand on this crazy idea with more craziness or see how feasible it is. This is a thought experiment on a really crazy idea.

1 Like
2

Depending on the information, you can currently store volatile information via:

  • Oracles - the oracle response has a TTL and then is gone.
  • AENS - you can have a pointer in your name that points to the resource in mind.
  • Contracts - you can store small pieces of typed data in the contract’s state

Note both of those are publicly accessable. If you have a side chain that stores the information for you - you certainly can pay miners fees there. I am not sure how this can be grown as a business model, though.

3

how is an oracle response gone? does it disappear from the blockchain? is it never stored? mmmm

4

:beers:

ok this says I need to post at least 10 words to offer you a couple of cold ones here you go

1 Like
5

Nothing is really ever gone: once posted on the chain - it is there forever. This is not the case as of what is currently in the state trees. Let me ellaborate a bit: imagine you have a contract that has a state consisting of a single integer variable. At one point of time it has the value of 42. At different block hash it is changed to 43. Now what is on the blockchain? Both values are there at different heights. At the current top though the value is 43.

Same goes with Oracle requests and responses: they live in the state trees temporarily and then, once their corresponding TTL expires, they are removed from the state trees. If you ask a node for the response at a certain height when it was in the state trees (and those state trees had not been GCed) - you will get the response. If you ask according to the current top - you will not get the response as it will not be available in the state trees. Same logic stands with expired Oracles themselves or Names (AENS).

Edit: this is sort of described here. It looks like it could be improved…

1 Like
6

Yeah so that is my point, the secondary chain would need to be not only garbage collected but also destroy the data after the TTL has passed. in such a fashion that the secondary chain has to be lightweight but also linked to the main chain. O_O

:beer:

7

So again 2 things here:

  • once TTL height is reached - data is kicked out of state tree from this height on but it remains in previous state trees
  • if you enable the state tree gargbage collector - it will purge old state trees :slight_smile: thus effectively freeing the space

Both of those are already implemented so you can keep you secondary chain really lightweight :slight_smile: You will still need to have some archive nodes (with no GC enabled on them) so new peers can actually sync.

8

I’m not sure if I’m missing something but why would you need an archive node to sync? Isn’t the syncing node build it’s state based on blocks/MBs during the actual sync?

9

Yes, as long as you don’t start garbage collecting the transactions you should be fine w.r.t. sync.

1 Like
10

But are you saying garbage collecting things in a node makes it unable to let new nodes sync?

11

To sync a node from scratch you need to be able to re-create the complete history of the chain. To do this you need all the blocks from the chain. So a node that you can sync from needs have exactly those. @dimitar.chain was discussing garbage collecting the state tree (the Merkle Patricia Tree structure is normally append only) - this is orthogonal to sync.

The only care you need there is to not garbage collect information that you want the node to provide, for example answering “account balance at height” is hard if the information about that account at that height has been garbage collected. (Note: you can always start building the chain from scratch, but that might not be very practical :slight_smile: ) So, there is a trade-off, and things like the middleware can be a good complement.

1 Like
12

But in an “ideal” world you could snapshot the state and make the start a given height, so instead of having to rebuild all past transactions you start at a specific point with all the information having trimmed or slimmed or shaved all the blocks behind a specific height.

This is the idea for the linked chain, so when you say you need a node that is not garbage collected I am confused because if i can’t garbage collect a node that has data that is meant to expire (and thus not be recovered, accessed or rebuilt from the node’s states) then it defeats the purpose.

In this “idea” the secondary node could decide what data to prioritize (higher paying data would make it into more nodes). Again this is a crude and not even well thought out idea, and I really appreciate the input you guys are giving me, it helps me a lot to polish it.

:beer: ?

13

I think he means you need an archival node ( a node with all states, untrimmed, unshaved, non GC’d) to sync start up nodes from, assuming all the active nodes are non archival, any new node will need to catch up to this state and without the archival node it wouldn’t work. The state will be lost in the process and sync’ing is impossible without a node with all the data.

14

If you want to sync a node from height X you need a snapshot of the full active state at X + all blocks from X to the top of the chain.

The full active state needs to contain all active information (current state of accounts, all live oracles, all current contract states, etc) but can otherwise be garbage collected. I.e. it needs to contain everything that the transactions can reach, but nothing else. It is all about accessible and necessary information, information that isn’t needed can always be GC:ed.

3 Likes
15

Yes, I’ve messed up a bit above: sync and GC in its current form are orthogonal: even if your node is GCed, it can provide other nodes with blocks and transactions to sync.

1 Like
16

Sorry, I do not understand the meaning of orthogonal in this context (maybe too many beers?)

I understand garbage collecting is done in the state, while sync is done from the chain.
My most pressing question is, can the chain be trimmed or thined and still allow for new nodes to sync?

1 Like
17 
orthogonal /ɔːˈθɒɡ(ə)n(ə)l/
adjective
1. involving right angles; at right angles.
2. statistically independent.

In this context is it “currently GC and sync are independent from each other”. Yes, you can trim state trees and you can still provide blocks and transactions for other nodes to sync.

18

Ok, that’s a new word and it is great news :grin:

1 Like
19

More call center jobs need to be in place before launching new fortunes. That’s all oracle use is. Also needs an embedded contract for oracle to be disposable on apple user interfaces. Can’t split laptop on Mac so oracle should be apple based. Jobs should deploy resources faster in contracts. Jobs shouldn’t require interview. Less work is being sought

1 Like