Safe Computation, Apps & Plugins

Maybe instead of elders configuring which plug-ins they support, there could be special plug-in nodes that elders could contact.

Then network manages global list of all PLUG-IN nodes that support that plugin. So it is like hasmap { plugin_id_1 : array of plugin nodes supporting this plugin_id_1, plugin_id_2: array of plugin nodes supporting plugin_id_2}.

When elders get a request for using a certain plugin, they wouldn’t then use IP:HOST of the plugin node to connect to, but instead the xor address of the node found in the list of plugin nodes.

1 Like

YUP, you sumarized is pretty well. Here are some notes:

Elders can remove their plugin support anytime, they can fail to deliver a result. If they do not deliver reusult they just lose option to support that plugin for some time. They are punished only if they deliver wrong result, that is different than others delivered. So elders are responsible for quality of plugins, not for technical difficulties that could happen.

The Machine that is running the Elders vault does not do the computation. Computation can be done anywhere, but ELDER is responsible for the quality of that computation. He can lose a lot if the plugins is not working properly, and he is rewarded by direct payments on plugin call. So yes, the physical machine running vault is not running plaugins, but a human owner of the Elder vault is running those plugins and the trust is gain thanks to option to punish him when the plugins does not work properly.

I think it is very simply possible. We have a storage which is atomic and we can read and write into it. o there is not a problem to store current state which elders support which plugins and a setion associated to the client calling the plugins can pick a random X of those elders. And the section just need to let know other sections to pusnh the elder, in case elder returned different result than the consensus result.

It is like on normaln internet, when I load some page, I trust it because there is a history of trust, or do not trust it at all. The certificate signing the data just says this: plugin_ID calculated this result from this request. If I trust pluginID, than I can be pretty sure I can trust the content. If that plugin is some unknown crap, I do not trust it.


Nope, I was thinking for few years already how to bring bitcoin realtime copy and other blockchains trusted realtime copy to the safenetwork. And there was not an easy answer. With trusted copy of bitocoin network it is super easy to create a wallet that works simply on safenetwork and allows to make it native part of the network. Reading data is everytghing, writing to blockhain is super easy, for that I do not need anything just some centralized boradcast of transaction. But trusted copy needs decetranlized aproach and that is what plugins solve. And by a side effect they solves everything, any data from outside world can be copied into safenetwork storage in decentralized and trusted way in realtime.


Yes there could be plugin nodes, but the reason why proposed elders is, that they can be punished and lose a lot if they cheat. Plugin nodes on the other hand did not have to work hard to become elderes, so there is no way how to punish them. Also this could be solved by some safe coin collateral. plugin node could pay some fee upfront, that he would lose if he delivers result that is not compatible with others. But this is still a vulnerability. Because an attacker can risk losign money by spining many such plugins. But attacker has much more difficult task to build many elders to perform such attack. So it is all about option to punish bad behavior. That is why elders. But if we find a way how to punish them, then it can by other way.

A problem that came to mind in the case of the Bitcoin plug-in is that blockchains provide only probabilistic finality. This means that it is perfectly valid for different nodes to have different views on what the current state of the network is. This is why there are occasionally orphaned blocks, and why the rule of thumb is to wait 6 blocks for high value transactions to be considered final/confirmed. So the plug-in idea would be valid for things that elders would be willing to attest to as being final (ie 6 blocks deep and unlikely to be reorganized), but a “real-time view” doesn’t really exist.

yup, I have think about this already. It can be solved simply on plugin level by marking the result as not definit. So let say, network asks plugin to deliver a block number 34584, plugin knows this block is old, so it returns the block and mark the result as absolute. This means other plugins have to deliver the same. Now, if the call asks for plugin that is let say the latest one, then plugin delivers the block and makrs the result as unclear result. This way all the plugins mark result as unclear and those plugins that deliver different results are not punsihed, because there was a consensus that there is not an absolute truth. The result computation message can contain all the variyin results. It is up to people how to decide what to do with the result. Whether to wait for confirmation, etc. Blockchain is a tree, with forks. So if plugins decide there is not absoulte answer there is no reason to punish for such result. So it just brings another state to result. States are: result is absolute(punish those who are outside of consensus), result is non conclusive(do not punish anyone and return all the results), fal to deliver any result(do not punish elder, just remove him from list of active plugins)

Seems like there will be trouble if people keep asking for a block that is 6 blocks old. Maybe a majority of elders say they have seen the new block and mark the 6 deep block as absolute. But the newest block hasn’t propagated yet to some others, so they vote their 5 deep block as unclear. Would they then be punished? They didn’t do anything wrong. If they are not punished, what would their incentive be to mark anything as absolute?

This is simply a logic of a plugin. Plugin developer can decide, that if block requested is older than 100 blocks, than it is abosulte. Or even plugin developer can decide that there is not absolute result ever. In that case plugin call will return always all the computation without punishment. And people will decide which computation they trust based on % of same results. Yup this bitcoin example is little bit complicated, but is doable with this aproach. But there are tons of well defined data, that don’t have such issues. In fact just a simple list of all computed result signed with safe network certificate is enough to make fully working blockchain software. The consensus handled by network is just about punishment. If there are 90% same results and 10% different users can still work with that. As with any crypto payments, it is up to user to decide how many confirmed blocks he needs to feel confidend the transaction will not be reversed.

Yes, not very simple for Bitcoin. I think there is an issue in setting the “truth threshold” (unsure → sure) used for punishment. If it is block based, you are going to have the same issue of different nodes receiving blocks at different times. It doesn’t matter if the threshold is 6 blocks or 100 blocks. If it is time based (is block X seconds old), likewise you have different elders receiving the request at different times and therefore reaching different conclusions. Distributed consensus is certainly not simple.

You are right, it is not easy task. But there is a simple solution. If it is block based, and let say the plugin marks blocks older than X blocks as finite, than the sync problem can be solved like this: those plugins that have more blocks will and are asked for a block that is exactly X blocks old will mark the result as finite. Those plugins that did not receive last block will mark the result when asking the same block as not finit. And since those plugins did not return finite result, they can’t be punished for their computation that is out of sync. And those plugins that returned finit result are used as consensus result. No conflict there.

So what is the incentive to ever commit to anything as final?

Maybe, No final, no reward? Plugin sets the rules. If there is consensus that something is final and some return not final, then we can reward only those with final. Or reward only those who return the same result as mayority.