Architecture issue

[clearmatics]

Architecture issue

[HarryR]

Yup, seems like you're taking the right approach.

Although one thing I want to salvage into its own project is the auto-completing CLI for Solidity ABIs, that's a cool snippet that deserves its own home. (i'll extract that at some point).

Let me figure out what I'm doing in the coming weeks, but it may be worth popping into the office for a day for a hackathon and some whiteboarding/waterboarding.

[daragao]

I really think that the ability to have Privacy will improve a great deal the possibilities of the design, you are right.
The reason why eventually that event relay would be trustless is that the Root would basically be the top of a tree that is composed of signed leaves (giving some assurance of trust). Right now though, the focus on how that tree is created, just makes us focus on something that isn't the larger problem which is:

1. If A withdraws than B can withdraw (or vice versa)
2. How can we allow for refunds to happen if one of the parties never deposits or withdraws?

[Shirikatsu]

Following from @daragao, the two points he mentions pertain to being able to synchronise state between two chains and only allow things to happen given a condition on another chain. This introduces an aspect where we need to define where the source of finality is and how we can achieve this finality in a trustless way.

[HarryR]

Hi.

https://github.com/clearmatics/ion/blob/master/contracts/IonLink.sol#L70

This proof of concept doesn't have authentication.

The previous iteration used the 'Owner only' model.

ion/contracts/Sodium.sol

Line 63 in 18bebbb

require( msg.sender == Owner );

iirc there was a separate component called Beryllium which manages who is authorised to perform updates, and who is authorised to change who is authorised etc. etc. This is a 'Trusted' model where some trusted entity says who's allowed to update the roots.

There are a few different models:

1. Use a trustless relay, on-chain verification of Ethereum block headers, see https://blog.gridplus.io/efficiently-bridging-evm-blockchains-8421504e9ced - however, this introduces significant complexity and makes verification of specific events cost more & take up more space (e.g. instead of a merkle proof you have to provide lots more data, where essentially the whole transaction is relayed to every other chain as part of the proof, rather than the much shorter merkle proof)

2. Use a centralised component which checks if somebody is permitted to update the component with a new merkle root (aka Beryllium) - single point of authority / failure.

3. Use a decentralised consensus of independent IonLink instances which are updated by different parties, this on-chain consensus is linked to multiple instances of IonLink which are updated separately, when verifying it will check if a majority/super-majority agree on the merkle root of that block etc.

4. ... possibly some other things rattling around in my head.

The only way to solve this is to only permit a trusted centralised service to update IonLink, but then it become centralized and there are much more easier way to solve the problem when you can afford to trust a centralized service..

Correct. But see alternative for on-chain consensus...

Anyway, with SGX, we can deploy smart contracts having secret data on-chain, for example in this case, IonLock could have a private key to sign that it has received funds and then the problem is easily solved.

facepalm Please don't attempt to use SGX. It's not what you think it is and will introduce a whole new world of pain at every aspect of deployment, integration, maintenance, testing etc. heed thy warning... Not to mention vendor lock-in, incompatibility with most cloud platforms, horrible horrible complexities and gotchas. Another question would be - why SGX and not TPM or an external security module? They both have all of the same basic problems though.

---

Please close this ticket and create a new one to address authentication / authorisation, rather than the vague title of 'Architecture issue'

kthxbai

[daragao]

Thank you @HarryR for pointing those out, you are absolutely right.

Our first goal with Ion was to strip the problem to the most basic shape, and we got it that it doesn't work as intended, when we allow anyone to update IonLink/Sodium (avoiding single point of trust). Why release it than? Just so that we get the ball rolling and get used to see what others have to say about the path we are taking.

We are now mostly focused on how to achieve either model 1) or 3), since they seem the most interesting ones. We are still learning on how to do this well enough to make something interesting.

About the SGX approach, we aren't going there for now, @yazzaoui and others are working hard on figuring out how everything in it works. Although there are interesting things there, it does seem to have some big pain points, the most obvious being vendor lock-in (but like any privacy solution, there are others).

happy to hear more in the future ;)

[daragao]

Yeap ;) let's do that!

[Shirikatsu]

@HarryR Sounds good! Let us know when you're available :)

[maxrobot]

I am closing this issue as I think we all understood the problem and have moved forward in our thinking regarding cross chain swaps.