19 April 2023 / 09:00-11:00AM (UTC-5)
Council: Elation Studios, Ryan, M&N, Strawberry Council, Sash, DR, Song Sjun, Rebecca, Phantz
Secretariat: Cassie, Greg
Jingyu, PG Bao, Infi
- Recent BPoS upgrade issues
- CR standby nodes
- Multichain support
- Witnet support for ESC
1) Recent BPoS upgrade issues – Bocheng
- Bocheng attending.
- 5 things happened.
- Block height specified for the BPoS start was reached.
- Only 25 nodes had completed the upgrade (not enough with new software).
- Blockchain stopped.
- 12 hours later, the mainchain reverted to PoW.
- ESC/EID both stopped producing blocks.
- Attempts were made to contact node owners to get updates done.
MButcho – There were considerable problems regarding the deployment, poor comms and no clear process or means of resolution throughout.
Finally, a website or resource with all node owner details is needed to help problem solving. This tool is required to identify issues in a timely manner. And a way to contact node owners is needed. Everything took too long and the transparency was unacceptable.
Bocheng – risk of sharing IP address etc., which isn’t desirable. It is risky.
Fakhul – Agree with MButcho plus…a full post-mortem needs to be shared. All could have been avoided if two things happened:
1 – Super clear that all nodes needed to be upgraded (this wasn’t understood).
2 – The majority of the SNs in the East upgraded in time, the Western nodes did not. There were few comms between the two groups. Ti from Info was the liaison but he has gone now so there was no simple comms route. A better way to share information and offer guidance would have solved this problem entirely.
Bocheng – Centralized risk of sharing information, APIs, IP address etc., which isn’t desirable. It is risky.
MButcho – A solution is possible that doesn’t disclose anything. CLIs. Although a centralized website isn’t ideal, the node can self-check and report to a website.
Bocheng – There is a script but it can’t monitor proactively. Another idea is to work on a script that can track blockchain data for confirmations for each node.
Fakhul – ESC and EID upgrade is coming soon (May?) so we have to be better prepared for this.
Cassie – Testing is underway. Deadline in June. Will let you know.
2) CR standby nodes – Mbutcho
- ELA available for running standby DPoS nodes.
- Fakhul loaned ELA to get these running. 3x extra nodes are now running and will continue until BPoS is active.
- 3 extra nodes now running.
- When we transition to BPoS can it revert to DPoS? If not then we can shut down this proposal.
- Confirmed, so terminate this proposal.
Bocheng – Yes, no going back.
MButcho – Why 80k minimum? This is not tenable for a standby node proposal similar to this programme. Once the DPoS is terminated a different approach is needed to ensure it can’t go offline – reserve or guarantee voting power for standby nodes; or reduce the 80k minimum.
Fakhul – Council have the treasury address for emergency voting to maintain BPoS?
MButcho – the 80k minimum votes is there for an unknown reason.
Cassie – This proposal needs to be carefully considered with regards to how it can be used for BPoS.
Fakhul – If the public nodes drops below 36 will the chain revert to PoW? (Or do the 12 council nodes mean this number is lower before reversion to PoW.)
Bocheng – 25 is enough for public nodes. Will double check with Gelaxy team
3) Multichain support – Elavation
- Multichain is a major player in cross-chain bridging.
- Huge network connections.
- Low friction fees.
- They are willing to integrate and quickly – Bridge connection can be completed within a month.
- Makes it easy for new projects to join ESC.
- A proposal is coming if we can get agreement from ShadowTokens (ST) to collaborate.
- Staking is needed (MULTI tokens). Equivalent of ~10k ELA, over 3 years – earning rewards and would remain CR property/asset.
- The bridging into ESC has been a friction point for a long time.
- High minimum thresholds
- Limited chains.
- Not known or trusted in the wider DeFi space.
- Discussion has occurred with Song SJun from ShadowTokens.
- Trusted team.
- No exploits.
- Centralization concern to external projects and users.
- Not a well known bridge so is less attractive to new Elastos users than Multichain would be.
- Elavation recommendation: Combination of ShadowTokens and Multichain could be a great solution.
- Most bridges are routers – move existing tokens around, they don’t create them.
- ST is an asset generator – locks on one chain and generates on another (Lock/Mint).
- ST would be the canonical bridge and Multichain the end-user bridge.
- USDC from any Multichain network to ESC – needs ST rebalancing a pool for users (hidden from end-user view).
- Doesn’t replace ST, maintains liquidity that exists already – a neater solution for transitioning to a more robust bridge.
Song Sjun – Would a large liquidity pool be needed? On both sides of the bridge?
Ryan – Multichain would be able to create a synthetic version if liquidity isn’t sufficient in the pool. The solution isn’t clear yet and needs further discussion with the Multichain team. With ST team attending.
Song – ST is still working in a centralized manner. If the council wish for ST to decentralize then 36 nodes would be needed and the cost for developing this mechanism can be undertaken. One year costs.
Thresholds are 5000 for USDC from Ethereum with a bridge fee too. The team doesn’t earn revenue from the protocol. If this decentralization is deemed necessary by the council then it can be looked at – if funded.
Ryan – Next step is to speak to Multichain about how this could work with ST and Multichain working in tandem. The changes Song mentions aren’t critical at this stage.
Nenchy – Multichain is TOP, agree! Most famous, credible and brings a fantastic badge to Elastos. It’s an important addition to Elastos Smart Chain. Are you talking about both bridging and swap solutions with Multichain?
We need to get together to make this work.
Fakhul – ST would act as bridge in the background (users none the wiser, it’s all in the backend) for rebalancing pools for the Multichain Router.
We need the ST team to commit to this approach though before we continue conversations with Multichain
There are two ways this can work:
- Multichain bridges alongside ST (they compete) – but then you end up with multiple versions of ELA, USDC, BUSD, ETH etc.
- Multichain replaces ST, which is decommissioned BUT that will be a lot of work for Glide, users etc., (plus of course it’s up to ST what they want to do.)
Nenchy – We connect to Multichain and we can welcome 89 chains to connect with us – depending on assets supported on other chains. USDC would bring in lots of chains for example.
Elavation thinks combining both Multichain and ShadowTokens is the smoothest solution based on our current status but there are still some unknowns we need to work through.
Fakhul – Having 3 chains supporting ESC is nice; ST (native), ELK (3rd party) and Multichain (3rd party), other chains have many bridges.
Nenchy – Can we have a middle step bridging ELA alone to and from other chains, as Router route, where liquidity is not really needed. Or is it?
Fakhul – That is exactly what ST does, it’s called mint/burn (its what CreDA does for Arb <> ESC)
Fakhul – What is really good is Multichain are CN speakers and happy to collaborate with us to make it all work.
Nenchy – But minimums we have atm in place with ST, how would bootstrapping along with Multichain work at all?
Fakhul – So that is what Ryan describes. Users would use multichain without these restrictions and in the background ST would rebalance the LP as needed (so they become an infra layer).
Fakhul – ~10k ELA is needed to be used to stake – we still own it and get it back after 3 years. The staking time frame can be reduced but they require much larger amount in return. We also earn rewards from this stake. ST would own the process – and would request fees being covered through subsidizes from the CR. The plan is still being designed, and needs to be fleshed out more, importantly we first need agreement and commitment from both Multichain and ST teams.
Fakhul – Elavation recommends strongly that moving forwards with the collaborative ST/Multichain approach that Ryan outlined initially is the best way to make this work. A proposal for the MULTI should be submitted first. In addition Elavation will work with Song Sjun to create a proposal with multiple phases to support Multichain integration and ALSO support ST in development for decentralization. We will work with them to ensure they receive the necessary funding to support both Multichain and decentralization.
Song – Most of the costs would be for incentivize 36 trustworthy node owners to stake maybe 5,000 ELA. ST currently supports BSC, Ethereum and HECO.
Regarding the combination approach – if you submit a proposal you will need to add the 10,000 ELA for the MULTI staking and also liquidity pool funding. Multichain without this liquidity pool can’t really work.
Fakhul – The decentralization can be phased in over time. We needed to check with ST before going back to Multichain to explain the solution to deploy – bridge or router. ST team need to confirm whether they would be willing to support the collaborative approach we recommend.
4) Witnet support for ESC – Elavation
- Partners ask about oracles and we have to say no.
- Chainlink have been contacted but they have no intention of prioritizing Elastos without payment.
- Kava use Witnet already and they’re seeing considerable success and growth in DeFi. Professional team and easy to work with.
- Requested a subsidy for fees – a negligible amount of ELA is needed and Elavation or Gelaxy can most likely handle this.
Nenchy – Oracles are well known, and are also a potential weak spot for exploits. Do understand how the price feed is working because an oracle exploit would be very damaging to Elastos. If it’s solid and safe then all is well.
- Cassie/Bocheng – Will double-check with Gelaxy team about how many public nodes are needed before PoW reversion occurs.
- Elavation – Outline of how Multichain can work alongside ShadowTokens.
- MButcho – Look to terminate or modify the standby node proposal.