toggle quoted messageShow quoted text
> The most prominent item I see is Ethereum mainnet compatibility. Could
articulate the value of that in specific terms? I am familiar with the
notion of using mainnet as a receipt log. I would like to understand
other benefits and use cases for permissioned networks to link with
This quite a big topic, but I will give some examples I like.
First its worth noting for all of these use cases what is interesting is not just being able to 'do it on mainnet' -- anyone can send transactions to Ethereum from bash -- but rather having mainnet connectivity. The strongest for of this would be that a quorum (ideally any quorum) of your validators are jointly responsible for issuing transactions (via some kind of multisig on mainnet) and checking state on return (via multisig on sidechain). Lesser forms of connectivity might be via 'trusted' third parties or even a single service (i.e. an ethereum oracle). The effect could be the same, but in the weaker forms you have thrown away much of you byzantine tolerance. Ideally you want the same threshold for state changes on the sidechain as for state changes to the relevant contracts on mainnet. If all you require is a proof that a transaction was included (i.e. account X has placed a bond) rather than joint custody of an asset (i.e. paying out from the sidechain's reserve contract - where (super-)majority of validators must agree) then you can get away without quorum at the expense of liveness. To do this kind of strong connectivity it is helpful for validators on both sides (mainnet and sidechain) to be aware of each other. This is where Pantheon could help Burrow for instance - by pushing state back to us rather than us pulling - where a Burrow chain's validators would hold accounts on mainnet, and a validator pool from mainnet would hold accounts on the burrow sidechain. This isn't something we could get go-ethereum to do, but we might persuade Pantheon to provide this intermediate layer.
1. Bond-holding and value transfer.
This probably the most obvious one. Since eth is worth something you can pay people in it. In particular you may want to run micro-transactions on your chain that are secured against a bond placed on ethereum. In order to guarantee the bond you need to be able to observe that a reserve of funds are locked on mainnet, you also need to be able to atomically swap them which is where you need connectivity. For proof-of-stake chains on Burrow you can ask entities wishing to validate to store bond on mainnet, credit them with validator power on Burrow, and if necessary in the case of validator unavailability or equivocation to slash part of their bond on mainnet. We would like all of these actions to be under control of a quorum of validators on the Burrow chain. We can fudge it now, but proper connectivity is what we would like to do it well.
2. Announcement and light clients
I think your receipt log example would come under this bracket. The most interesting to me is announcing state hash, validator set hash, and seed location for a Burrow (or other) network. If I am a participant or validator wanting to join a Burrow network I would like to find out a recent snapshot of the validator set (their public keys) and also how I can connect to them. I could trust, say, Monax to tell me but I'd rather use Ethereum as a public system of announcement. If the validator set hash and state hash is updated in a timely fashion, as a light client I can use it to verify merkle proofs issued by a Burrow node without trusting that Burrow node so long as the history of the state root hash was updated by a quorum of validators periodically (and >1/3 of the set hasn't changed since the last update). This is great because I don't have to validator the entire Burrow network
3. Counter-factual instantiation
This language comes from 'state channels'. If we consider a sidechain as a kind of state channel with its own consensus where some counterparties can more quickly transact than they can on mainnet then they can go about their business issuing signed incremental transactions that would also be valid on mainnet. This works for micro-payments but can be generalised to any state where you have a rule that says the highest sequence number is valid. If the participants on the sidechain have a dispute they can all submit their latest transactions and an ethereum contract can adjudicate. At worst a participant on the sidechain only loses out on state since the last checkpoint they were okay with (e.g. before the sidechain suffered a sybil attack).
4. Inter-chain connectivity
Suppose I have two chains A and B, each chain has a total ordering of its own transactions. If I want to establish a partial ordering between just some transactions on A and B I can do that by instituting some form of meta-consensus on mainnet. This could just be a race if it is unimportant which transaction comes first or it could be some kind of conflict resolution. For example if my chain A is managing bills of lading for shipping and wants to issue an insurance agreement (b) on my agreements network B for a consignment (a). We can transact away on A building the bill of lading and follow a formation and signing process for the agreement on B before finally submitting an transaction on mainnet that defines the insurance agreement as executed _before_ the bill of lading is accepted. The transaction 'b then a' on mainnet is a kind of stronger guarantee that you were insured before you shipped (than say timestamps) - and it's also a public record of the fact. You then only pay the price of cross-chain consensus for transactions that need to depend on each other.
I don't share all of the fervour, and I'm not quite so bullish on Ethereum (though it does have that big advantage of being a thing right now...), but I think the following blog provides quite a nice frame for thinking about possible relationships between mainnet and permissioned networks:
First off thanks for all the work going into the proposal and the timely responses to this list and the wiki. While there is already collaboration with portions of the Ethereum and EEA communities, more involvement and collaboration is
always very welcome. I think this project could foster even more and I have a just a few questions remaining in my mind after reviewing all the comments in this thread and the wiki.
Adding another framework to Hyperledger presents both opportunities and risks. On the risks side, we are just now at a point where we were starting to see real progress on componentization and steps towards architectural convergence. A
siloed project could upset that progress. I appreciate the Besu proposers expressing a willingness to work with existing component projects (e.g. Transact & Ursa). Is Besu architected in a way to also provide components to the rest of Hyperledger? Are there
pieces that offer independent value?
On the opportunities side, with new frameworks we’ve always had a constantly rising bar… what does this new proposal bring that is unique to our greenhouse. The most prominent item I see is Ethereum mainnet compatibility. Could someone
articulate the value of that in specific terms? I am familiar with the notion of using mainnet as a receipt log. I would like to understand other benefits and use cases for permissioned networks to link with mainnet.
I look forward to discussing this proposal in our steering meeting tomorrow (8/22).
Chair, Technical Steering Committee
Joe - we can probably do it, and pretty quickly. We already have both Fabric and Ethereum nodes (full nodes) on the Unbounded Network for quite a while... and we are already bridging Fabric - Quorum (JPM's), etc...
I don't think being under the same foundation will guarantee that people actively "make it work". One can argue that some of the biggest Fabric supporters also part of EEA/TTI and still haven't made this a priority. I wonder who will spend
the money and time..
Also, for those more familiar with the Ethereum Ecosystem - there are so many tools that are not part of Hyperledger, from Truffle to Infura and I don't want to even mention block explorers and others. Do we want a commitment that all these
tools will be part of Hyperledger, or that code will move from these projects (some are with GPL and others) into the respective HL candidates? There are actually announcements left, right and center about truffle adding Fabric support, etc. These developments
are not done in Hyperledger.
What I don't understand is, since when we have ever required anything like some of the things I see below from a project at incubation? Shall we make these a future requirement?
I will put together a wider response tomorrow, actually with a few questions that I belive we should answer within Hyperledger first, before we make so many changes "after a proposal is submitted". We saw it with Grid, which required an
escalation to the board, and we are beginning to see some similar traits.
In the meantime, enjoy the Web3 Summit, Berlin BC Week, where applies.
On Wed, Aug 21, 2019 at 1:20, Joseph Lubin
We have also engaged in discussions for a year of so with some Fabric focussed groups around finding a project that would benefit from a Fabric-Ethereum bridge. To this point we haven't found a partner that was interested in doing this
with us, but I expect this will happen quite quickly if we are all part of the same foundation.
On Tue, Aug 20, 2019 at 6:08 PM, Grace Hartley <grace.hartley@...> wrote:
Here are our team's thoughts, but we'd love to hear the community's feedback as well.
In the short term we see the majority of interop and cross ledger communication happening at layer 2. We are actively working with teams
in the wider community to ensure that Besu facilitates layer 2 cross ledger communication, particularly working with the web3j team who are adding support for Hyperledger Fabric, and the Truffle team who are doing the same.
In the medium-term we are very interested in interoperability between chains, and we will be investing increasing effort in this direction,
and in doing so expect to leverage many of the existing Hyperledger projects to do so. The two most obvious projects for collaboration currently are Burrow due to it’s EVM execution environment and aim of providing
practical base for EVM extensions in a many-chain world. In addition we look towards working with Quilt for its implementation of the interledger
protocol. Quilt is a natural collaboration opportunity due to both the technologies it supports, and the fact that it is a JVM based technology.
Thank you Grace, for the kind response
How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other
yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.
Thanks for the thoughtful questions. We've responded to them below.
Why the name "Besu"? That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.
As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu”
means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.
Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that
have more direct connections to Ethereum will have trademark challenges.
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned
ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks
such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different
applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.
Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for
its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects.
We have ideas mentioned in the Proposal around who we can collaborate with.
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate
Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?
Why the name "Besu"? That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.
There were some trademark issues around "Pantheon", unfortunately
Why rename it?
Hi All, We are excited to share that
PegaSys, the Protocol Engineering team at
ConsenSys, submitted the
Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project.
We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment
directly in the Proposal document.
PegaSys and ConsenSys Team Joseph Lubin, ConsenSys,
joseph. lubin@ consensys. netDaniel Heyman, ConsenSys/ PegSys,
daniel. heyman@ consensys. netRob Dawson, ConsenSys/ PegaSys,
rob. dawson@ consensys. netGrace Hartley, ConsenSys/PegaSys,
grace. hartley@ consensys. netDanno Ferrin, ConsenSys/PegaSys,
danno. ferrin@ consensys. net
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged,
confidential and/or proprietary and subject to important terms and conditions available at http:/
/ www. digitalasset. com/ emaildisclaimer. html. If you are not the intended recipient, please delete