The SAFE Network is not a Blockchain

[betterthantrav]

For the newbies out there please read…

The SAFE Network does not use a Block-chain! I repeat the SAFE Network does not use a Block-chain!

A good way to compare SAFE to the Block-chain is to not compare them at all. Realize that one is not better than the other. But, instead understand that they are two totally different technologies that accomplish completely different tasks. The Block-chain is nothing more than a cryptographic, pseudo anonymous, ledger system, while SAFE is a protocol for a fully anonymous, serverless, cryptographicaly secured, decentralized computer network, that happens to have a ledgerless crypotographic currency with almost limitless transaction speeds.

[Nigel]

I think safe is actually superior in the way of being scalable and more evenly distributed. among being anonymous and now with data chains coming up also being able to provide cryptographic proof of purchase/receipt or even ledger features. Sorry blockchain…

[betterthantrav]

My worry is that new people will join the community and not realize that the SAFE Network is not a new Block-chain technology. But, instead something completely different, capable of everything the Block-chain can do and so much more.

[smacz]

Its just a buzzword. But for sure its frustrating when its referred to as a blockchain.

OTOH its a good turing test for new members…

[goindeep]

Great and bumping to top!

[enjoypolo]

I’m bumping this old topic.
So does that mean that the transactions (On Safe) are not ‘transparent’ as on the blockchain?

Can anyone mention what are potential drawbacks of the SAFE Network, maybe in comparison with the blockchain? I am aware it may be context dependent.
Thank you!

[Proteus]

Ledgerless? So there is no way to view previous transactions? (like a block explorer)

Thank you for this post as it does help. I’ve been meaning to dig into the inner-workings of the Safe network for a while now and am just now getting to it. Currently digging through the forum & github simultaneously.

[drehb]

@enjoypolo

Can anyone mention what are potential drawbacks of the SAFE Network, maybe in comparison with the blockchain?

It has a new consensus model, so we’ll have to see how well that holds up “in the wild”.

[intrz]

@Proteus

Ledgerless? So there is no way to view previous transactions? (like a block explorer)

There are plans to enable an optional ledger so you can view transactions, like a block explorer. I am not sure how exactly it will work, but I think it can be turned on and off for any given transaction.

[dirvine]

@intrz

There are plans to enable an optional ledger so you can view transactions, like a block explorer. I am not sure how exactly it will work, but I think it can be turned on and off for any given transaction.

The idea is (10000 foot view). For every MD version, we remove the old one (saves space as well), so for ledger bits set (an extra field possibly) then the payment for update is higher, but it means also keep this version, do not remove. This way we can have safecoin receipts etc. meaning when you make a transfer then you pay a little more but a receipt is kept.

[intrz]

@dirvine

The idea is (10000 foot view). For every MD version, we remove the old one (saves space as well), so for ledger bits set (an extra field possibly) then the payment for update is higher, but it means also keep this version, do not remove. This way we can have safecoin receipts etc. meaning when you make a transfer then you pay a little more but a receipt is kept.

So it would keep the history of any MD, including all changes to owners and permissions in addition to the data? Would it work in such a way that the history of a document stored as an MD would make it easy to make a wiki? Would it store just a diff or the whole version?

[elviti]

This thread is short but I think some posts presented some interesting questions that seemed to me that were not fully answered or addressed by the more knowledgeable members of the community…

[dirvine]

@intrz

So it would keep the history of any MD, including all changes to owners and permissions in addition to the data?

It would keep a version that had the ledger bit set, so not all versions, unless that was required.

@intrz

Would it work in such a way that the history of a document stored as an MD would make it easy to make a wiki?

It could do.

@intrz

Would it store just a diff or the whole version?

It would be the whole version at the moment.

[dirvine]

@elviti

This thread is short but I think some posts presented some interesting questions that seemed to me that were not fully answered or addressed by the more knowledgeable members of the community…

You should specifically repeat what is not answered, the folks here are generally good at covering all angles.

[intrz]

Perhaps instead of storing the whole version it could store the changes as events?

Some examples in JSON, of course the actual format could be some optimized binary format

A permission was added for a user to insert data
{ "eventType" : "AddedPermission", "signKey" : "signKey1", "action" : "insert", "permission" : "allow" }

Ownership was transferred
{ "evenType" : "ChangedMDataOwner", "newOwners" : ["signKey1"] }

The value of an entry was updated

{ "eventType" : "EntryUpdated", "updatedBySignKey" : "signKey2" "key" : "test1" "valueDiff" : "difference between current and last value" }

From the list of events each version could then be recreated, but you wouldn’t have to store the whole version.

It’s nice to know exactly what changed and also if you were to for example use this to make a copy of Wikipedia on SAFE, it would be a lot of extra data if every single edit made a new copy of the whole article.

This could be really useful for things like collaborative documents where you need an unalterable record who of did what changed. It could be used for publishing scientific articles for example. First a scientist would write the article, then send it to some editor that would do some changes, then it could be sent to peer reviewers that could add comments, the peer reviewers could even be anonymous, but assigned by some trusted source. Finally after going through some rounds the article could be set to published. Perhaps something like this would use a mix of immutable and mutable data though, like the final article might be a PDF stored as immutable data, but the record would be the mutable data ledger or something like that.

The diffs could perhaps be stored as immutable data, so you’d just store the xorname of the immutable data containing the actual diff, not sure if that would make sense or not though.

[neo]

@intrz

Perhaps instead of storing the whole version it could store the changes as events?

My understanding is not to give a version history which a “diff” or events would be good for, but rather as a Snapshot MD that can be used as a receipt for SAFEcoin transaction for instance. Or as a copy of the contract that cannot be altered, or as a copy of the contract on the day of start and on settlement. Two snapshots and there may have been changes inbetween as required but no snapshot or receipt needed. Just the contract when it was signed and when the contract completed.

The “diff” or events means then you have a ledger of all the changes to the MD that then requires reconstruction of the MD.

There is great power in being able to present a MD that is a snapshot and easy to work with.

Also the idea is not to keep a history of the MD but just the occasional snapshot of the MD if you specify that in the options for the “transaction”

[intrz]

@neo

The “diff” or events means then you have a ledger of all the changes to the MD that then requires reconstruction of the MD.

There is great power in being able to present a MD that is a snapshot and easy to work with.

There could be an easy to use API that could do the reconstruction automatically and then present the data as if it was stored as a snapshot.

The main difference I guess would be if you want to save storage space (save as events), or if you want to save processing power (save the whole data, don’t require reconstruction).

[neo]

@intrz

There could be an easy to use API that could do the reconstruction automatically and then present the data as if it was stored as a snapshot.

But not as good as sending to the lawyer the MD address as a “file” and he/she can check it. No need for special processing because it was a “snapshot”. To have event reconstruction then requires APPs to know about it and the receiver has to use that APP rather than a simple viewer.

Also are your “events/diff” meant to keep track of all changes to the MD? If so then its a big waste since when anyone turns it on for a SAFEcoin then all that coins history is being recorded and defeats the anonymity of safecoin transactions for that coin. I could imaging someone turning it on for all their own coins then watching the flow of transactions for each of those coins once they spend them

If the “diff/event” recording is for the single transaction then its waste of processing since you need a MD stored anyhow, why not just store the MD as is.

Maybe leave the diff/events stuff to an APP rather than at the network core level.

[intrz]

@neo

Also are your “events/diff” meant to keep track of all changes to the MD? If so then its a big waste since when anyone turns it on for a SAFEcoin then all that coins history is being recorded and defeats the anonymity of safecoin transactions for that coin. I could imaging someone turning it on for all their own coins then watching the flow of transactions for each of those coins once they spend them

I thought the owner(s) could turn it on/off. Anyway there are cases where you’d want to turn it on and then want to keep it on for a while. The UN Food Programme has been looking into using crypto for transferring aid money for example. In such cases you’d want to turn on the ledger bit and check that the money got spent on food and not a new golf course for some corrupt leader. You’d likely also want each transaction to be multisig, signed by both the aid organization and whoever was doing the actual buying, to prevent some corrupt official from stealing it, and then the ledger turned on so that the public could check that everything was spent appropriately. Eventually once it was out of that system it could be turned off again.

@neo

Maybe leave the diff/events stuff to an APP rather than at the network core level.

Perhaps that would work just as well.

If the amount of data wasn’t just a couple bytes it might in many cases be better to not store the actual data in the MD, but instead store a pointer to some immutable data that would contain the actual data, then if each version of the MD was stored it wouldn’t be a lot of data in any case and with the deduplication of immutable data the amount of data stored shouldn’t be that much.

[neo]

@intrz

I thought the owner(s) could turn it on/off.

All David has ever suggested that it is a option in the call to the api which keeps the old MD. So no ledger bit in the MD itself but ledger bit in the api call is how I understood it.

If it was a ledger bit in the MD and someone wanted a receipt for their payment to another person then that other person would have to turn it off. But who is going to be checking that the ledger bit is on?? So we have the situation that there could be a whole host of coins with the ledger bit on that people don’t turn off and this history is being kept and the people thought it was anonymous.