rjones (Thu, 27 Aug 2020 23:05:08 GMT):
User User_1 added by rjones.
rjones (Thu, 27 Aug 2020 23:05:20 GMT):
RafaelAPB
RafaelAPB (Fri, 28 Aug 2020 11:21:20 GMT):
User User_2 added by RafaelAPB.
RafaelAPB (Fri, 28 Aug 2020 11:21:21 GMT):
User User_3 added by RafaelAPB.
RafaelAPB (Fri, 28 Aug 2020 11:21:21 GMT):
User User_4 added by RafaelAPB.
RafaelAPB (Fri, 28 Aug 2020 11:21:21 GMT):
User User_5 added by RafaelAPB.
RafaelAPB (Fri, 28 Aug 2020 11:21:21 GMT):
User User_6 added by RafaelAPB.
RafaelAPB (Fri, 28 Aug 2020 11:21:52 GMT):
We now have a private channel to discuss the paper (direct conversation is infeasible because I cannot add people)
RafaelAPB (Fri, 28 Aug 2020 11:21:52 GMT):
We now have achannel to discuss the paper (direct conversation is infeasible because I cannot add people)
RafaelAPB (Fri, 28 Aug 2020 11:21:52 GMT):
We now have a channel to discuss the paper
RafaelAPB (Fri, 28 Aug 2020 11:21:58 GMT):
The updated draft: https://www.overleaf.com/7268869168dxnfvhpsfrzb
RafaelAPB (Sat, 29 Aug 2020 13:24:40 GMT):
User User_7 added by RafaelAPB.
DOBEN (Wed, 02 Sep 2020 04:22:14 GMT):
@Rafael: Thank you for initializing and setting up the infrastructure for this paper. This is a good starting point.
I added the text to the section “Limitations of current interoperability solutions”.
I am aware that it is still a bit of a debate if Cactus records transactions in a central blockchain or not, therefore I added a section with question marks and would only include it if we can actually generate a convincing showcase in the numerical result section where the Cosmos's Hub or the Polkadot's Relaychain becomes a bottleneck due to the processing/storage in the central blockchain but the Cactus network does not. Ideally, we can proof that "`The Cactus network is designed so it will not become the bottleneck."' somehow in the numerical result section.
Does anyone know if Cosmos/Polkadot proactively include every transaction, happening in one of their connected blockchains, also in their central blockchain (hence some metadata has to be stored/processed in the central blockchain even so nobody has requested a proof or an interaction yet) or is it happening on demand meaning the central blockchain only processes/stores transactions that were actively requested? If Cosmos/Polkadot work proactively than we can try to generate a bottleneck where every connected blockchain processes transactions at a high frequency but we only do inter-blockchain interactions at a low frequency. As Cactus only requests proofs on demand it is more efficient in this scenario than having to process/store every transaction from every connected blockchain proactively as it is done maybe in Cosmos/Polkadot.
Alternatively, we could try to show that Cactus has a lower latency since it does not need to wait for finalizing the central blockchain or requires less storage.
RafaelAPB (Wed, 02 Sep 2020 08:16:12 GMT):
I believe that in Polkadot, all parachain blocks are validated on the relay chain, in a parallel manner.
RafaelAPB (Wed, 02 Sep 2020 08:20:16 GMT):
However, taking into account their parallelization power, I believe they can handle LOTS of transactions;
Pág 35: https://www.researchgate.net/publication/341785543_A_Survey_on_Blockchain_Interoperability_Past_Present_and_Future_Trends
https://polkadot.network/the-path-of-a-parachain-block/
sfuji822 (Thu, 03 Sep 2020 02:17:47 GMT):
@jweate @peter_somogyvari I see PR#190 https://github.com/hyperledger/cactus/pull/190 is still have a issue to be merged. I think you need to execute rebase for passing commit check. Since we would like to use your plugin at the demo application, please tell us about your plan to fix the issue.
jweate (Thu, 03 Sep 2020 02:17:47 GMT):
Has joined the channel.
RafaelAPB (Sat, 05 Sep 2020 19:30:52 GMT):
User User_8 removed by RafaelAPB.
RafaelAPB (Thu, 15 Oct 2020 19:03:50 GMT):
Discussion on the academic paper
RafaelAPB (Thu, 15 Oct 2020 19:04:18 GMT):
Public mirror for the academic paper: https://www.overleaf.com/read/mgvtzpxjmzfj
RafaelAPB (Fri, 16 Oct 2020 19:11:38 GMT):
Dear all, I kindly ask you to provide me your Overleaf account, please.
peter_somogyvari (Fri, 16 Oct 2020 19:13:03 GMT):
My username on overleaf: peter.somogyvari@accenture.com
hartm (Fri, 16 Oct 2020 20:40:05 GMT):
I'm hart.montgomery@gmail.com Thanks!
RafaelAPB (Sat, 17 Oct 2020 17:40:59 GMT):
Invited!
rjones (Mon, 19 Oct 2020 16:36:18 GMT):
@mwklein
rjones (Mon, 19 Oct 2020 16:36:55 GMT):
User User_9 added by rjones.
rjones (Mon, 19 Oct 2020 16:37:10 GMT):
Why is there a password on this channel? What is the concern?
RafaelAPB (Mon, 19 Oct 2020 16:46:51 GMT):
Hello @rjones. Shouldn't be a password here. All opened!
rjones (Mon, 26 Oct 2020 23:10:56 GMT):
@JuanNogueira
JuanNogueira (Mon, 26 Oct 2020 23:10:56 GMT):
Has joined the channel.
JuanNogueira (Tue, 27 Oct 2020 22:53:42 GMT):
Hi guys. I've reading the paper and trying to understand the way cactus resolves interoperability and I've got some doubts
JuanNogueira (Tue, 27 Oct 2020 22:54:00 GMT):
1. Is there only one ledger plugin per blockchain network or is it one ledger plugin per node? I mean, if I have two blockchain networks with 10 nodes each, do I have 2 ledger plugins or 20?
2. Applications that use the blockchains, perform all the calls to the routing interface of cactus or do they perform calls directly to the blockchains too?
3. Business logic plugin runs on only one node? I mean, is it centralized?
peter_somogyvari (Tue, 27 Oct 2020 23:15:23 GMT):
@JuanNogueira
1: However you choose to do it, can be either one of those according to your needs/constraints in your production environment (which we don't want to have strong opinions on hence the flexibility)
2. If Cactus does it's job right then your application wouldn't need to talk to the ledgers directly at all (which is our claimed value add, when we call it an "SDK of SDKs").
3. Sorry to keep saying this, but it depends on what is it that you want. :-) BLP is really just a placeholder for your use-case and the code specific to it. It doesn't even have to be deployed on a Cactus node as a plugin if you don't want it to, because your code can just call the Cactus API that runs on a different server entirely (if that's what you want for whatever reason).
In general: I know it sounds like I'm not really answering the questions and just keep saying "it depends", but I really hope that this will turn out to be or greatest strength on the long run because once people come in with specific and detailed use cases I will be able to give them answers based on those that will have a much lower amount of of forced trade-offs compared to us being strongly opinionated up-front.
JuanNogueira (Wed, 28 Oct 2020 22:25:50 GMT):
It did clear things out. Thanks!
brunob15 (Tue, 03 Nov 2020 23:10:10 GMT):
Has joined the channel.
avradip (Thu, 05 Nov 2020 00:25:25 GMT):
Has joined the channel.
RafaelAPB (Thu, 05 Nov 2020 15:33:43 GMT):
@hartm hey! Did you have the chance to check the presentation from last Thursday. Your input would be quite appreciated regarding the security properties proposal for Cactus. Cheers!
hartm (Thu, 05 Nov 2020 15:34:04 GMT):
Yeah. I'll try to send out a mail on that today or tomorrow.
hartm (Thu, 05 Nov 2020 22:13:36 GMT):
I took a detailed look this afternoon. What's the best way for me to comment?
hartm (Thu, 05 Nov 2020 22:15:08 GMT):
I'm mostly in agreement--there are only small things that I want to nitpick (e.g. we may have a scenario where Cactus routing needs to be BFT, not just CFT, and similar things).
hartm (Thu, 05 Nov 2020 22:15:23 GMT):
The next step might be to define an ideal model.
hartm (Thu, 05 Nov 2020 22:15:38 GMT):
If people agree and think that is useful, then I can get started on that.
RafaelAPB (Fri, 06 Nov 2020 18:09:20 GMT):
I think you can directly comment here or in the mailing list. Feel free
RafaelAPB (Fri, 06 Nov 2020 18:10:43 GMT):
For me the ideal functionality routes the defined business logic (as arbitrary as we find secure) to the specific underlying blockchains (via routing interface -> connector), and retrieves proof via the validator/attestator. After that, that evidence should be persisted (e.g., local storage, cloud, or distributed)
RafaelAPB (Fri, 06 Nov 2020 18:15:09 GMT):
Participants:
-Cactus nodes
-Blockchains
Not sure if we should consider end-users that operate Cactus as participants (although they might interfere with the nodes); Considering the connector and validator part of the cactus node, if the node is malicious, so are those components; except that we can try to base our trust ground on a validators' quorum
hartm (Fri, 06 Nov 2020 18:21:26 GMT):
Great!
hartm (Fri, 06 Nov 2020 18:21:48 GMT):
In the ideal functionality, we should define Cactus as a trusted third party that honestly and correctly handles all transactions.
hartm (Fri, 06 Nov 2020 18:22:09 GMT):
We need an untrusted environment: delivery may be faulty, and we still need guarantees.
hartm (Fri, 06 Nov 2020 18:22:39 GMT):
We need to choose some kind of synchronous model (i.e. assume that there is some rough notion of time shared between nodes).
hartm (Fri, 06 Nov 2020 18:24:12 GMT):
In the "real" functionality, we'll want end-users, Cactus nodes, blockchain nodes, and (probably) more. We'll have an adversary that is allowed some formula for corrupting these.
hartm (Fri, 06 Nov 2020 18:24:44 GMT):
And we'll want to show that, modulo our assumptions, this "real" functionality is indistinguishable in a UC-like sense from our ideal functionality.
hartm (Fri, 06 Nov 2020 18:24:56 GMT):
We may also want to assume some ideal functionality for blockchains.
hartm (Fri, 06 Nov 2020 18:26:19 GMT):
Also, I don't know if you've seen it @RafaelAPB , but I tagged you on the github issues: Peter @peter_somogyvari created some github issues related to privacy-preserving transactions between blockchains. There's easily another academic paper of work in this, and we probably need security proofs before we make this feature live in Cactus (although I don't expect it anytime in the near future). You may want to take a look at it.
RafaelAPB (Fri, 06 Nov 2020 19:11:44 GMT):
That makes sense - although i thought we would want to model Cactus with an asynchronous communication model - you would prefer to model it as a part. synchronous system?
RafaelAPB (Fri, 06 Nov 2020 19:11:53 GMT):
I haven't seen them but I'll take a look
RMX (Fri, 20 Nov 2020 13:35:04 GMT):
Has joined the channel.
heena066 (Thu, 03 Dec 2020 09:10:57 GMT):
Has joined the channel.
AllanLundHansen (Fri, 19 Feb 2021 11:17:33 GMT):
Has joined the channel.
RafaelAPB (Thu, 04 Mar 2021 21:09:24 GMT):
@hartm do you have any comments on the CIP, presented today? After thinking if this is a good protocol candidate, it is easier to define the necessary interfaces and do the UC work
peter_somogyvari (Thu, 04 Mar 2021 21:10:06 GMT):
(Recording and slides are up on the meeting notes: https://wiki.hyperledger.org/display/cactus/2021-03-04+Cactus+Contributors+Western+Hemisphere+Meeting+notes )
kenty (Sat, 06 Mar 2021 16:02:35 GMT):
Has joined the channel.
RafaelAPB (Thu, 18 Mar 2021 16:26:11 GMT):
Couldn't attend this week's meeting as I'm sick. Any major updates?
peter_somogyvari (Thu, 18 Mar 2021 16:26:30 GMT):
Almost done with the meeting notes
peter_somogyvari (Thu, 18 Mar 2021 16:26:58 GMT):
Just having some trouble saving the document in Chrome for some reason /facepalm
peter_somogyvari (Thu, 18 Mar 2021 16:36:50 GMT):
Meeting notes are up: https://wiki.hyperledger.org/display/cactus/2021-03-18+Cactus+Contributors+Western+Hemisphere+Meeting+Notes
peter_somogyvari (Thu, 18 Mar 2021 16:38:05 GMT):
And to answer the specific question, no major updates I'd say, but we did have a productive session in terms of discussing the paper, performance tests and terminology.
Also, the maintainers' meeting will be at a slightly more Europe friendly time next week (specific link for this is in the meeting notes)
RafaelAPB (Thu, 18 Mar 2021 23:11:07 GMT):
Thanks @peter_somogyvari
RafaelAPB (Thu, 18 Mar 2021 23:11:13 GMT):
Definitely agree with the deadlines.
jscode017 (Tue, 27 Apr 2021 14:24:03 GMT):
Has joined the channel.
jscode017 (Tue, 27 Apr 2021 14:24:35 GMT):
Has left the channel.
pranjay (Fri, 07 May 2021 10:12:36 GMT):
Has joined the channel.
Sandyzhanghs (Sun, 09 May 2021 07:20:42 GMT):
Has joined the channel.