Blockchain Text - Version 1
a guest Mar 26th, 2019 171 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
- There are more and more initiatives by politicians (or even people) to introduce more and more censorship. I would like to see a platform that prevents censorship (unless the interface introduces it, but I would like there to be more interfaces), and people can freely share their content.
- A decentralized database / Blockchain must, in my opinion, meet a number of conditions:
- * Be easy to reproduce
- * Resistant to censorship
- * Prevent spam (as far as possible)
- * Anyone can be a node
- These are my observations, I don't know if it's possible to build an entire content storage network.
- The data stored in the database must be done in such a way as to store the least content. Paradoxically, it is difficult to store a very large number of messages, it often takes several TB of data. You have to do everything to keep data growth as small as possible.
- Why? We cannot prohibit anyone from holding data in blockchain. If someone wants to make a page with pieces, they will do it. If someone wants to do "pastebin" on Blockchain, they will do it. Our task is to do everything so that the network does not collapse.
- In my opinion, the problem is the size of the text data. We can allow people to write short or long entries (e.g. 8KB). Each of these methods has its advantages and disadvantages.
- In my opinion, it has to work like this when the user wants to add this entry:
- * The entry is checked if it wasn't the same before. Sometimes it can be a short message ("Hello!"), which will be used by many people. Instead of storing it again, it is worth indicating where the database was the same.
- * Each language should have its own compressor dictionary. Before an entry is added to the database, it should be recognized linguistically and compressed (ZStandard looks very good) using this dictionary in order to save more space.
- * The entry should be added after the Proof of Work action. The point is that spamming bots consume a lot of electricity for a long time to make spam unprofitable.
- * The entry is added to the node and propagated.
- More and more portals rely on short comments (~500 bytes), so I don't know if it's better to store short entries.
- Editing an entry is creating a new entry (and linking in a special JSON field), and the differences between an old and a new entry should be created using a comparison (as in diff) - what has been added, what has been removed, and not throwing the file again (unless it is more cost-effective).
- The JSON field (as in Steem - JSON_metadata) is used to store various data needed by interfaces, such as message language, tags (if supported by the interface), links to thumbnails, the interface used by the user, etc. The JSON_metadata field is used to store various data needed by the interfaces. This should be a small data field
- I don't have a good idea for authorisation. Maybe there should be an "auth" field that stores a message signed by a given user? But which one? Maybe a separate blockchain / field? What if I lose my password / private key?
RAW Paste Data