Monetary value as data object or projection of ledger entries

Development
,
1

A few times now, I have in my explorations of SAFE come back to safecoin and transactions.
I thought I’d offload my thinking here, put it to print, and hopefully get some new angles.

The differences between representing a coin with a data object, and as the result of ledger entries, seems to result in some differences in what we can do. Maybe my appreciation of the issue is disproportionate, maybe I am seeing a very small slice of the problem (well, more than likely that would be the case). But anyway, let’s see what we can arrive at.

If we look for example at a concept called event sourcing, it enables us to do things which we cannot do in an application architecture based on the traditional implementation of OO and another db structure than ES.

Accounting for example is event sourcing. It is a practice with millennia of use. When implementing event sourcing, I can represent a transaction between n different accounts, with the persistence of 1 event. This event either exists, or does not exist. There can be no inconsistencies. Like a ledger entry. (And this is the source of truth. Everything else is just a projection off of it, your account balance for example i.e. the number of safecoins you have.)
Trying to do this with a monetary value represented as a data object would not be possible. When you do the operation of mutating the state in one place, you also need to mutate state in some other place, for this transaction to be complete. It will always be a 2-phase commit, which inevitably will always be less robust than a 1-phase commit.
And something makes me think that this practice of accounting has shown to be very very robust as to survive for such a long time. It is as old as civilization itself. Now, this is not ants-old :slight_smile: . But it is one of the older parts of the things humans has invented.

And there are some other things resulting from this, I believe.
I have been thinking about smart contracts on SAFENet, and I still need to do more research on the SAFE technology to open up my views on how this could be implemented.

But.

If monetary value is represented as valid ledger entries, and a valid ledger entry is one with sufficient number of signatures, I see the process of transferring monetary value within SAFENet as a much more trivial task, than if the monetary value is represented as a data object.

Because, the actual signing of the ledger entry (the last one needed) is what ultimately will materialize the fact that it is now a transaction. It either is, or is not valid. And there are no additional actions needed but the signing.

That is not the case when working with a data object - as far as I see it at least. First something has to gather enough signatures, then this something has to act on that information.
Yes, a smart contract protocol on SAFENet could be constructed much like the disjoint groups, and a node with higher trust (age) would carry out the actions that the group has decided on. But I cannot wrap my head around how this is not a vulnerability. This is still 1 node, that supposedly uses legit source code when making the decision. But it has the power to carry out the operation regardless. … … … That is basically what I do not understand, how to safely let one node have this power.

It might very well be that I’m here just showing a fundamental lack of understanding this (how a safecoin transaction would be made for example), especially since I have not yet delved down deep enough in the system, the documentation and the discussions, as to be able to answer this for myself.
(And of course, the safecoin implementation is still very much subject for R&D for what I can see.)

Now all of this is without regards to the brilliant idea of the recycling of safecoin, and how this is enabled just because it is represented as a data object.

5 Likes
2

I’m not 100% in this, but I think it is more like N of M nodes have to have signed before a change is valid, in which case a coin / transaction is never in the hands of a single node. Look out for the dirvine like, or not!

2 Likes
3

So far, that’s my conception too: N of M nodes sign.
But technically, what is the actual action / recording / execution of the transfer?

If it is not the result of the signatures, over one ledger entry, it is - as I see it with data object - a transfer from one object to another. This must be performed by one entity.

In here is where the conundrum lies.
Representing monetary value as a data object, requires a different way of representing a transaction. Not saying that it would be inferior or not possible, but it seems to me less trivial, and I do not see exactly how, while maintaining same level of security.

2 Likes
4

Yes, I see what you are saying and can’t recall enough to answer so will have to leave it for somebody who can go into the detail. I’m not really sure that it’s that different an issue with a ledger: to be accepted, an entry in the ledger is only accepted based on a similar process - effectively a vote - but again, I don’t recall the details well enough to say more than that. It’s too long since I read this stuff on depth!

3 Likes
5

Yes I agree, voting is part of both.
But as I see it, the actual voting is all operation that can, shall and is needed to be done in the ledger case.
Example (not trying to state something obvious to you but just refining my description):
A ledger entry is created as a proposal by a sender or recipient. An MD.
To be valid, sender + quorum of some secure group must sign it (maybe recipient too).
When it is signed by all necessary parties, then that is that. This is the transaction.
No moving around of data. Just add signature.
Can’t be more secure than that, no? All a node can do is create a proposal, sign or not sign.
The balance is a projection of (valid) entries like these. Not represented as an object that can be split, or moved or has a physical location.
No one has power to transfer anything, no inconsistency is possible (reduced amount here and now we shall incr… Oops … lost in some transient glitch).

With a data object on the other hand, it seems to me that we can not produce a transfer from one object to another (we are actually moving bytes now), without authorising something to do this transfer. That is giving a lot more power to one single party, than what was needed in previous example.

So, basically I just wonder (asking anyone who might know :slight_smile: ), is this a correct understanding? And if so, I guess there is a solution to this, but how?

6

Could be just me but I don’t really see what you’re getting at. As far as I understand no data object (MD) is moved around the network for an ownership transfer, it’s indeed just the attached signature(s) representing ownership.

Edit:

Is your issue with the fact that because it’s a data object the older signatures are removed and only the latest version is stored? There are always multiple vaults keeping track of a data object and they are monitored by other nodes close by in the network address space. If one of those vaults tries to randomly swap out the signatures then the inconsistency is eventually detected and the vault will be banned from the section. To pull off this attack you need to control a majority of vaults managing that data object, but your vaults have no control over where in the network they end up doing work.

Edit 2:

It might interest you that with Project Decorum we’re implementing our own design for a ledger-based coin where the entire history is immutably stored (in a tree, not a chain). So both models are possible in SAFE and they of course have their own up- and downsides.

10 Likes
7

Well, I guess what I am lacking is the understanding of the exact technical details of a transaction.
And true, no MD is moved around, they have their fixed address. And strictly the bytes of the amount is not moved around either (in my careless misrepresentation, sorry about that), but a request is made to do something, which might lead to +/- of bytes in some place.

If I look at your description, it seems to me you might be describing a single write operation to an MD, overwriting previous owner with value of new owner.

So, if write permissions is set to owner A, then when transfer is carried out (let’s not bring in divisibility just yet), owner A updates the MD (at address S, so MD_s) by doing the following (in one single request! paramount to not have the n-Phase commits…):

Add write permission for B
Remove write permission for A
Write to OwnedBy field: B

So, now safecoin MD_s is owned by B and can only be modified by B.

(This might not be correct understanding either, but we have still not reached the example I was thinking about. I will have to restart from the beginning if I am wrong at this point here.)

Over to the example.
A smart contract is about to transfer ownership of amount from A to B.
Then we have N out of M nodes that need to agree on the smart contract conditions being met.

If we look at above example for ownership change, one way for this to work (without single party having this power I mentioned), to actually perform anything, some party would have to add each of these nodes in M to some multi sig list in the MD_s.
Now this is a proper rabbit hole in itself; How are these added to this list? Is each node in a group adding the signatures of all others in the group (but not itself)?
But again, this is perhaps not at all how it is supposed to be done. (I wonder how though?)

Now, what is the actual transaction consisting of here?

Each node n in N will provide their signature to some sort of proposed state change on the MD, asking for the same things as above

[Proposed state change when N out of M has signed]
Add write permission for B
Remove write permission for A
Write to OwnedBy field: B

When the state change has taken effect, the transaction is done.

I am wondering how this state change is carried out.
I would be happy to understand the details of it.

My thinking, where all started, was that there is a difference between carrying out a state change in a single write - as it requires a single party, and on the other hand having a transaction object, that is considered valid when there are enough signatures on it.

With rules like these:
The transaction object either exists or does not exist.
Before N of M has signed it is not valid.
Before N of M has signed it is therefore just a proposal.
After N of M has signed it is the very fact of a transaction.

  1. we avoid inconsistency in data (balances not adding up due to failed n-phase commits).
  2. we avoid the necessity of a single state change that would need to be carried out by a single party, thus giving this single party a power that is hard to control.

So, I don’t understand the details of how it is actually supposed to work, and can only guess (or spend more time trying to find the answer in docs/discussions, that is true):

In technical detail, would it be that there is a field named “StateChangeValidOnQuorum” in the MD, with the value of the above proposed state change when N out of M has signed, and that this value is considered valid if count of sign. (in some other field) equals count of N, and is a subset of M?
(I don’t think it would be this, but just trying to get to it).

What I considered a vulnerability, was if there will be one (any) party, carrying out the actual state change above.
Since it is not clear what I am getting at, it is likely that this (one party carrying out the state change) is indeed not at all how it is (supposed to be) done, and that it indeed is so far from any proposed concept that the whole question is not making sense.

Might be so. But then, how exactly is it done?

Edit: correction of formulation about agreeing/quorum.
Edit: disambiguation (done => carried out)

4 Likes
8

Safecoin transaction though will be implemented as a atomic opeation. That is from the outside of the box the coin is transferred between people as a singular operation. Just like a real coin you pass it from one person to the other. And as @happybeing says it requires consensus of 2 sections to perform the transaction. Normal MD operations only require the one section (the one handling that MD object)

Safecoin is in not trying to be a ledger style of system, but simply as people physically use fiat coins.

Have a read of the safecoin category topics and there are a few topics with some good insight to the safecoin.

Please note that MD objects will have multiple owner ability turned on in a later alpha/beta. So coins can be owned by multiple people and have different modes, for instance 1 of many or most or all

tl;dr

SAFEcoin is in no way trying to operate like a ledger or block chain. Its security is along the lines of the security for any data object, with the added security of a second section some distance in XOR space from the section in charge of the safecoin MD when doing owner change (transfer). The transfer is atomic meaning it must be completed before any other operation on the coin can be started. It more emulates one person giving another a physical coin.

A ledger system is performing much more than safecoin is trying to do. The purpose of safecoin is for paying of resources, for example pay to store or rewarded for retrieving data.

For a ledger then no cannot be more secure I guess.

But safecoin is in no way trying to be a ledger system or a substitute for one. It is compatible to using physical coins, even down to each coin being a physical MD object

So the security is that the coin is physically existing and owned by someone. The only way to lose the coin is to forget about it or the network fails and if the network fails then we pack or bags and forget SAFE. For a ledger if the majority of the people holding a copy of the ledger forge entries in their copies then they can change history. The ledger itself is unsecured (eg bitcoin) and its security is the large number of people holding a copy.

If SAFE wanted a ledger system for their coin then they could have implemented it with the inherent delays of such a system. If I wanted to spend then the network has to trawl through the ever increasing ledger to find out how much I owned and see if I can indeed spend a coin. Then how does one secure such a ledger which is a programming module in itself and increases the attack surface of SAFE. The safecoin uses the security model of the network so only special part is the actual transfer.

SAFE went for the Fast and Simple approach of physical coin transfers and no need or want of keeping track of the spends.

ALSO keeping a ledger loses one of the Big advantages of simple transfers and that is anonymity and personal security. There is no way for any entity to track anyone else’s spending giving true anonymity, true security (from effects of tracking spending), network secured coins and more.

6 Likes
9

I get what you mean.

But if you carry that logic to the rest of the operations in the SAFE network then the whole of the network is vulnerable.

But this is what a lot of the programming and innovative workings of SAFE is about. The consensus model does what the ledger model does with everyone holding a copy of the ledger. Except the consensus model does not need everyone to agree, just the members of the section/group.

In effect if you feel that the consensus system is inadequate then the whole of the SAFE network is inadequate since the consensus mechanism is the very basis of the security of the network. It is what stops anyone from interfering with data stored on the network.

Then the coin transfers require 2 sections/groups to perform the transfer.

Maybe do a study on consensus (search on that word) and you can then understand further what it is all about.

tl;dr

consensus is what makes the “single” party incorrect. It is multiple parties unrelated to each other apart from forming the section/group that makies the decisions.

2 Likes
10

I’m jumping in and addressing your OP without having read the rest of the posts, because I don’t want to forget my perspectives. Mea culpa if others have already presented a more sensible perspective.

Safecoin can definitely be viewed as a data object, but there is a perspective by which you can view it as a ledger, to wit:

The “safecoin space” is a ledger of 2^32 slots. Each slot either has an existing safecoin or it doesn’t. If it has one, or one is created to go there per the rules of safecoin creation, it has a cryptographic owner listed. The state of that ownership can only be changed by the owner cryptographically.

I don’t think that’s quite the truth of things. It has to do with consensus is reached and actions are overseen. While one node may get the lead on writing a safecoin change, it has to be done per cryptographic signature that no one has but the safecoin owner. If that node sought to execute something different it would be caught out, whether it had senority or not. To make such an illicite change would require getting control of a quorum of nodes in that group, at an exact time, coordinating what would add up to an insignificant gain in itself. If you study up on the consensus form (which can take a bit of study and head work) you’ll start to get the picture.

May I commend to you the SAFE Network School podcast, especially Class IV, and Class IX, and perhaps VIII also. With disjoint groups and a couple other advances, there may be some variance from the current model, but the basic concept apply.

The School series not a perfect tool (having been put together by a technical simpleton), but anyone who isn’t familiar with the different aspects that make the SAFE Network different should benefit from them, at least from a high level.

Enough tooting my horn. Hope that helps. Now I’ll read all the other replies and decide if I should delete this one :grinning:.

[Edit] One additional thought while reading the other points is to remember that what the network does with safecoin is what the network does, period, except that safecoin is a reserved data type which the network accepts and gives in exchange for resources. The handling of safecoin is therefore not a special security case. All data is handled the same, including safecoin. That might be considered as a slight to the security of safecoin, but I think it is really elevating the security of DATA at large up to the level of currency.

9 Likes
11

Hi neo, thanks for the long reply! With all respect, it seems a little bit handwavy to me. I’m sorry, I do not mean to be rude. It’s just, I have been reading about the consensus model and the disjoint sections and data chains option B and even coding some simulations. I am aware of the concepts, it is not the cause of my question. I now wonder about technical details of a very specific part.

I do not like to use these kind of words because they are used in so much polemic situations, but it is a strawman argumentation about safecoin not trying to be ledger. I never claimed that :slight_smile: I never asked for that either :slight_smile:

There are two specific points I describe and I am describing how I see that solved with one method, but cannot see how it in detail is solved with the other.

You are getting close to the actual subject here:

But, again, then how? Technically. In detail. (That’s what I wonder, I do not require you to answer it, I just wonder if anyone knows?).

(I need to get down to the kitchen and make some waffles with my spouse :slight_smile: I’ll write more soon. Again, sorry neo for the short reply and rough formulations, wifey calls. fergish, thanks! I’ll come back later and reply :slight_smile: ).

1 Like
12

I think what @oetyng is lacking is a nuts and bolts description of how a transaction is carried out. I can’t provide this atm, but it occurs to me a misconception may be that there is ever one data object in one place, which makes it vulnerable to one controlling node.

Perhaps this is avoided by each approved operation needing to be carried out on every copy of the data? I can see how that would avoid the perceived vulnerability, but I’m not sure if this is the actual means by which it is achieved.

Alternatively I think @fergish may have hit the nail on the head with this, so a bit more detail around it might be the key:

Anyway, I think this is the area needing clarification.

2 Likes
13

Sorry not trying to be. Its just the consensus model is what SAFE uses to secure data which includes SAFEcoin objects. And if you feel after study this is not good enough then what can I say? I tried to give an overview of how consensus is not a “single point” of agreement, but is in fact many points have to agree or it doesn’t happen. Also I would not have explained so much to be handwavy

Not intended as such. I thought if you knew (or confirmed it is such) then it would aid in your understanding. Also if the intention is to be similar to physical coin transfers then relating it to a ledger in any way shape or form unless just as a pure comparison is just talk.

Well the code is not written, but basically the section/group of nodes handling the safecoin object refuses any other operations until the current one completes. The section/group checks the request for transfer is valid, then asks for further consensus from the other section/group of nodes and if all is OK the owner of the coin is changed. These sections/groups are unrelated nodes that have to agree on an action before it can occur. This is a huge discussion on how and it would be best to follow the links others have given and /or do a search on consensus.

Also calling my addition to what others said as handwavy is well … maybe showing that consensus doesn’t ring true with you yet. And since SAFE is built on the consensus model, not much of the security will ring true until your understanding of it grows.

1 Like
14

Somehow I missed out on the existence of this site. I listen to your podcasts on the forum when they come out but didn’t know you’d done a set of backgrounders collected as a ‘School’. Have now seen the error of my ways and added it to my 10 key facts post.

5 Likes
15

I should not have used those words, they are too loaded. It turns the discussion the wrong way :slight_smile: Let’s get back to the technical details.

I’ll just clarify: I wanted to say that the actual detail I am elaborating around, is at a very basic technical level, how in practice a specific step is performed, and that at the very point of writing the data that seals the transaction, there is no exact information - as I have seen - about that step. And that with a smart contract scenario, that brings up some questions.

So, what I think is not coming forth in my texts, is that I am not questioning safecoin or its design or its rationale.
I am not advocating ledger instead and I am not saying it should be one way or another. I think this is a disclaimer that needed to go on top. My bad for missing that.
I did however point out that ledger systems, like accounting, have been tested for a long time, and just like we like to refer to natural systems and assume that just by their mere longevity they have proven to be robust and carry an innate elegance/simplicity, I also thought that maybe (maybe) this is true for accounting too, since, although not ants-old, it actually is one of the oldest inventions of humans. But, that was with a large maybe.

But, now that I have explained that, let’s go back to the technical details. that is still the main focus.

There is a final step, in a transaction that is done when a smart contract is to be enforced. I described how I see that potentially happen, I pointed out the exact location in a supposed rough algorithm, where I see how two different systems would handle it differently, and that it seemed more trivial to me with one of them, and that I was still wondering about the last step in the safecoin implementation.

So, there’s a lot of eventual consistency in the network. I am quite familiar with eventual consistency, and that it does not require atomic operations - on the higher level. But, we’re still at a very high level here, we are going much more concrete:

You describe a situation here

I am in the details in the very last part of that sentence: the owner of the coin is changed.

I believe, if you read my texts again (if you feel up to it :slight_smile: ), with that in mind, my reasoning would make more sense.

In any type of system, that specific step is present, so I guess we can start with the details of it, then we can zoom out and see how that fits in to the larger concepts.

@fergish is, just as @happybeing observantly notes, getting close to this too:

I recognize this model in the very first post. It is just that, this is still not the exact description. And I am aware that safecoin is still in R&D (also mentioned in OP).
We’re quite close here to describing it, it seems like the knowledge is there. I’ll give it a try from this description above.

  1. A node gets a leading write of a safecoin change.
  2. This nodes does this per cryptographic signature of the safecoin owner. (hm?)
  3. This node has the power to write some other data than intended, but will be punished if doing so.
  1. This seems to say that there is an order, there is a leading write and then some following writes. What are the steps here? What does the write consist of? Is it a signature added to a field of an MD?
  2. I think this part is fuzzy. The leading writer uses the public key of the owner to sign what? This is not how I understand signatures, you use your own private key to sign something, it is then verified by others with the corresponding public key.
  3. Here we are touching one out of the two specific points I have been elaborating around. One node having the power to do an arbitrary write. We assume that it will not happen because it will not want to be punished.

First of all, is this even a correct representation?

If not, how are the exact steps carried out? I mean, the exact steps of this part might not have been decided, and I have not seen them in the general descriptions, so I do not require it to exist, but if it is out there it would be very nice to see it.

For anyone else who is wondering, as soon as I know the exact steps of MD mutations as a result of a smart contract condition being met, and being enforced by a group in SAFENet, I will explain it here. Maybe someone else will come first, but if not, I will lay it out here. That is a promise :slight_smile:

3 Likes
16

Because it has not been written. But I gave you the process that will be followed. It is atomic.

If you call it a smart contract then we’ve been using them in operating system programming for a long time. Atomic operations in operating system design/programing has been a necessary fact since the very first time sharing OS written in the 60’s. I’ve written a few myself and the atomic operation is very basic in structure. You accept the request and lock out any more occurring till the first one is finished. Look up semaphores in relation to OS design.

In operating system on a single CPU it was turn off interrupts - set semaphore - turn on interrupts - do operation - turn off interrupts - clear semaphore - turn on interrupts. Then CPUs came with a atomic semaphore instruction that could not be interrupted by interrupt or DMA which could then be used on multi-core to do atomic operations. In other systems they usually use a Operating system call to do it. In networking then queue of requests is often used and the process handling those requests have a lock mechanism. In database then its very similar where a lock is implemented within the database code.

So like those in SAFE the section/group will first check the request and if valid lock the requests for that particular coin and prevent another one for that coin starting. Then the consensus process starts (insert a volume of description here - ie go to github or other doco and spend a week - yes dismissive but truly it will take that long to grasp the workings and security of it). I described the basis of this process already. The final stage of changing ownership is the same as for any other MD object and can be examined in github now, or a search of this forum on consensus.

Yes it is difficult to get reasons or what a person is driving at in a couple of paragraphs.

So no SAFE will not be what crypto sees as a smart contract. It is a consensus of at least 64 computers in two section/groups checking all the things that need checking and crypto signing messages that will allow or deny the transfer.

To call it a smart contract is to imply that a lot of work is being performed by multiple sections of code.

But NO it is using the consensus mechanism that is at the heart of SAFE, maybe you could call the heart of SAFE’s security (consensus) one big distributed smart contract machine. But that implies that someone writes a contract and the system operates on it with a deal of complexities. But no it is a very simple system that uses the network consensus to do what it does for all other data objects except an extra step of confirming the transaction with another section/group of nodes.

I don’t have the exact process but it is in github repository under the consensus mechanism. And is why I keep saying, search on consensus and study it up. It’ll take a lot of reading and to describe it here is not a simple task.

The ownership changing is the same as any other object that has its owner changed.

If it was as simple as giving it to you in a paragraph then I would, but it is a indepth discussion in and of itself. Personally I don’t know the precise ownership change code to be able to give you chapter and verse for it. But I do know from what you wrote that you do not have enough knowledge of the consensus mechanism to go into that depth here.

Maybe @tfa or @mav can explain it in one paragraph, I cannot. I would ping David or other dev to but they are too busy.

3 Likes
17

Perhaps I can help a little Group Consensus with owned data (such as safecoin) means this:

  1. A user / Peer requests an action. (could be ownership change, or mutate the data inside the MD etc.)
    2: Send this action to the address of the MD
  2. The X nodes closest to that address then:
  • Confirm the Signatures etc. are OK
  • Vote for the action to proceed
  • Gather Votes from the group responsible
  • If enough Votes accumulate then the data is changed.

The whole network or any user can then confirm this has happened and the MD has this new “state”. It can only go to one new state at a time (they are versioned) via the group consensus. So several attempts to change this state (like doublespend) will fail and only one state change will occur. You will see an advanced version of this that allows branches of possible next state in Data Chains part 1. An overview is here

Using versions is a CDRT type see here albeit this also requires consensus (the group agreement). There are more advanced methods that can be employed here, but it’s also a reason for not actually deleting stuff internal to the network, although in the API it may look like it is deleted. If you alter remove a version the CRDT like behaviour fails.

Then to add a little bit more for perspective.

The group closest to an address (responsible for changing it) are called the Data Managers, they cannot locate themselves on the network, that is randomised on join and also on every relocate (see node age RFC).

A wee bit deeper (sry)

Now every node involved in the above consensus agreement (the Data Manager) is also an address on the network that has a set of Close Nodes, just like data. So these have another set of close group nodes surrounding them. This group is the Node Manager group. So if a node does bad things or requires monitoring this group do that. as they are then the Close Group to the node they can also agree the node’s fate, just like agreeing a data element should change. So each node must follow the rules and the rules are set, but enforced by a set of nodes close to the address of the “thing” in question (node/data etc.) where each node is allocated work and rules to follow by the network.

This all happens with every change to any data or network membership (nodes join/leave etc.). So each node “sees” their own network (XOR distance means each node has unique distance to every other node) but it’s a view close enough to obtain consensus like this, but we know when we want X nodes close to an address, the network view from that address means there are strictly X nodes close to this. I mean there are no nodes that share a distance so each node is a unique distance and therefor there can be only X nodes close if there are at least X network nodes in total, and we can then set X to a figure that means the network traffic is not huge, but large enough security is maintained. This is the always trade off we consider, so things like larger groups not all holding all the data each etc. are great, or larger groups where we can use things like nodes connected to few members is great (i.e. connect to a strongly secure connected graph and not each member) or even where we can potentially have nodes more trusted than others that can reduce traffic flows (node age is promising there). Atm we go for high security and forgo performance to get to launch, but these are the kind of things that will increase efficiency at no meaningful reduction of security as we move on.

Hope that helps a bit.

11 Likes
18

@oetyng, I found this post from a couple of years ago where someone has basically said what David just did above but perhaps a little more concise. Just click on the quote title and it should take you to the post in the topic. Actually you might find the whole topic interesting even though some of it is outdated.

Also when you read what I quoted remember that group size was 4 for testing and is in no way suitable security wise.

@dirvine, is the following quote accurate enough?

6 Likes
19

Thank you for taking time and write to me @neo. I think we are talking around each other a little bit though. And @dirvine, thanks alot. I would have to improve my formulations, so that you don’t have to spend time on explaining things that I was not really addressing (from my view at least). I am sorry about that. But I really appreciate that detailed answer David!

I spent last week translating the code in Prefix.rs, XORName.rs and routing_table/mod.rs logic from Rust to C# (because I wanted to use the real logic in my simulations, and because I find it easier to understand by implementing it myself), and the weekend before that I implemented a simple DataChains simulation from this description: https://forum.safedev.org/t/data-chains-general-rules-in-an-eventually-consistent-network/687. I read about CDRT from other topic where this was discussed the other week, and I am familiar about the node aging and churns and how this prevents sybil attacks and so on. I do know the consensus model, I know how it works, I know what it does. But my question is about something else. I hope I will be able to explain exactly what my question is about.
I do not claim to understand all just because I read it, far from. I’m just saying that I am not as unfamiliar with it as you might think. I do realize that my inability to clearly communicate my question is probably not helping in that matter. I will keep trying though :slight_smile:

Skip this part if you don't want to read the long background

I do not refer to SAFENet as the smart contract. I am talking about something akin to implementing a smart contract framework in/on SAFENet. Which to me, in the absolute simplest form, would be an app with a specific purpose, that is communicating with other nodes running same app, and reaching consensus on something. So, not a general purpose smart contract framework, but one single app, with a single purpose, but that reaches consensus about the output from the operations of its source code. A DApp.

When I come to the end of the explanation, I think also the mentions of atomicity, 2-phase commits and eventual consistency might make more sense. But we’ll see if I manage to express the thinking clearly enough.

As I started the topic, I have been thinking about “smart contract” implementation in SAFENet; execution of code by nodes, and reaching consensus upon the output and performing some action as a result of it. (<- Here is the crux, but we will come to this.) The way monetary value is represented, was part of the crux. But again, we will get there.
I will detail it as far as I can, so that I can point at the exact location where the logic supposedly sits, that I am trying to specify and reason about.

So, we have code that shall be executed on various nodes. For reaching consensus about the output we can very well use much of the logic SAFE already has in place for creating and managing groups.
If we want to duplicate this (i.e. we know that maidsafe developers are focusing on other things now, and will not incorporate this into network at this point), we create an app, which reuses the same logic. Now, stay with me and let’s not focus on the duplication of the logic. We assume we can reuse the ideas, and adapt to our specific needs.
So the functionality is about managing groups, much in the same way as in SAFENet, but additionally running code with some input and voting on the result of running this code.

Let’s say I have a matching app for ads (just an example). (Note, this can be done in many many ways, and the point is not that, but in the end, where the specific action is to be enforced by a group. We will get there, I will tell you when we are there, but it seems I need to describe a lot more of the background. So we’re at the background stage now.)
A number of users in the network runs this app. Every time a user places an ad, there is some logic run, in this user’s app, with regards to how to proceed with the operation. There could be some initial MD stored, and then messages are sent out to a group with responsibility for this ad. Let’s say that is the case.
When the members of group G receive message saying “At address S this MD is stored, of type this and that, which means you will run logic L with the input in fields X, Y, Z in the MD”.
Each member runs the logic, produces output in some MD we name B, and each of them sign the output they have calculated.
When N out of M signatures are available, we can consider the output stored in B to be valid. This output can be used in consequent operations, and so it can go on…
Let’s get concrete again.
We had a matching app.One user places an ad. N nodes in a group responsible for this ad, will run code that finds the perfect match for this ad. They will vote on this. The output is thus a matching ad. It could be an address stored in MD named B.
Let’s say this app has some other functionality too. That when an ad is matched, there is some monetary transaction being made. (We’re getting close to the crux, but yet far away).

Now, I am trying to understand the exact details of how the monetary transaction is being executed.

Here below we have all the steps in the above, and this is all just the way I have understood it to be required.

But, again the very last senctence: then the data is changed. This, exactly here is the crux I have been circling around from the very start. Nothing else.

How, in technical detail, is this data changed? Is one node responsible for actually updating the MD?
I have tried to imagine what is going on there, because I think this very part is not implemented in code (multi sig, transaction of ownership), but I think it would be simplest if this part is explained, confined to that single step: then the data is changed. That there is the transaction being sealed. This is what I have been talking about all the time.
We are so close now :slight_smile:

Maybe there is no exact description of this, but if there is, it would be really nice to know it.

5 Likes
20

Thanks a lot for that link @neo. I’m delving into it later.

This here is about the same thing that I tried to describe in detail in one of the previous posts.
Just the algo for how this is achieved with an MD, step by step. I did a sloppy suggestion, just to hint at what level of description I am thinking about.
Like this part the group must sign off on any change for it to be valid. It is like the ledger example, that there is no single operation by a node, changing the state of an MD. But the state change is proposed, and then is considered valid as the last required signature is written.

I will look further in that topic and see if I can find such a description there.

2 Likes