XDC2.0: Security and Scalability with Sovereign Subnet by Gerui Wang (@GaryWang523)

Transcript

good afternoon my name is Gary welcome to the xdc session and today I will introduce you xdc 2.0 security and scalability with software evm compatible subnet first I will introduce you to xdc network then I will show you our core protocol from xcdc 1.0 to 2.0 then I will introduce our unique and crucial service namely forensic monitoring service then I will show you our scaling solution xdc subnet

the xdc network is an open source carbon neutral Enterprise grade evm compatible layer 1 blockchain it was a first and the only blockchain to be invited to join the trade Finance distribution initiative it is a Consortium of the world's leading bank and non-bank financial institutions for the purpose of liquidifying uh trade Finance we also call ourselves the xdc network the third generation of blockchain so the first and the second one they are Bitcoin and ethereum

for the transaction per second xdc reaches over 2000 TPS and the average gas fee is extremely low the transaction confirmation is two seconds and with finality financial means there's 100 guarantee it is not probabilistic and for smart contract support xdc network is yes it has evm compatible smart contract support and for energy consumption this it is very low it is almost negligible it is because we do not use the proof of work mining of Bitcoin or ethereum I mean the Eastern 1.0 before the POS

merge oh next I will walk you through our core protocol from FDC 1.0 and to our upgrade 2.0 so xdc 1.0 it is a highly efficient and fast consensus protocol it uses delegated proof stake depots this means that every node needs to stake 10 million FTC token to be a masternode candidate and we will elect a fixed number of mass nodes from

the candidates currently we elect 108 masternodes and this number can be scaled up when the network rolls so it works as follows the master nodes they are in an order list and they take turns to produce blocks and when they produce blocks they sign the block and in the figure it is denoted as N1 the first signature to make it more secure we have the double validation mechanism which means that signatures from two muscle nodes is required for each block and only with two signatures the block can be accepted by the network

it works as follows so actually are randomly assigned a second masternodes denoted as M2 needs to sign the block and I am happy to announce that our upgrade uh our consensus approach upgrade to xdc 2.0 consensus protocol which is more secure and faster it use the state-of-the-art presenting for tolerant consonants protocol which means it is secure even when one third of the masternodes goes adversarial it also has super fast transaction

finalization only three blocks for a transaction to be finalized and the finalization is deterministic which means 100 and the transaction is never wrote back and the most important service we provide by xdc 2.0 is our built-in forensic monitoring protocols this means that attackers who wants to create a fork on the blockchain and break the consensus they will be slashed with their stake tokens and we have a theoretical guarantee for that I will come to the forensic monitor later

so how does 2.0 work so instead of the double validation which requires only two signatures we require signatures from two-thirds of the current of the master nodes So currently we have 108 masternodes which means we need uh two-thirds times 108 but plus one which means we need 73 signatures from Monster nodes for each block this increases the security level and the 73 signatures constitute a quorum certificate or QC which is a crucial Concept in our

protocol and the QC is carried by the next block so the use of QC enables the xdc network to upgrade the consensus to the host of consensus which is the state of the art consensus in both Academia and in industry uh it works as follows so the protocol proceeds in rounds like run one run two and so on and again in each run there's one blog producer who should produce the block after this producer or proposal who produced a Blog it propagates the blogs throughout the network and other

Master nodes when they receive the block they should first validate the block that is check whether the block itself is valid it's valid and then it checks whether the proposal is the correct one specified by the protocol if these tests are passed then the the masternodes volts or sign a signature for this block and also propagate this Vote or signature throughout the network it is a duty of the next block proposal to collect the votes from two-thirds of the master nodes which is 73 volts and combine these volts into a

QC so this means that the QC is piggybacked by the next block that is block 2 is piggyback QC for Block one block three piggyback for Block two and so on so it's a little bit complex but the advantage of this complex consensus protocol is that we have fast and secure finalization uh proved by the hosta of protocol in theory only three consecutive QC I mean a block is finalized forever and with 100 confidence this means that if the block interval is two seconds three block is only six

seconds six seconds you can confirm a block and the block is never going to be rolled back or reverted uh throwing in the figure so after the proposal standard block the all the master nodes should vote for the block and hopefully that two-thirds coron of this monster nodes the both of these monster nodes will be formed very quickly okay next I will introduce our unique and crucial service namely forensic monitoring service

for instance monitoring service means that whenever any Master knows they turn adversarial and they want to create attack to the blockchain our service can detect the attack and can hold the attackers accountable we have two very important points to ensure that first is that why our product design the attackers must send signatures to launch such attack and these two signatures is actually the evidence of this attacker the evidence will be collected by our

service and then the evidence will be sent to a Smart contract and the rules specified by the inside the smart contract will slash the attacker stakes and they will lose their stake tokens and this is a very simple example shown in this figure that is at the end of this blockchain there are two blocks at the same height which means there are two forking blocks because maybe some honest nodes or normal notes they are in different locations or their Network conditions different so some honest nodes sign for one block and the other honest sign for

another block but it's okay what should be held accountable is the adversary shown in this figure that who signs two blocks or Volts for two blocks and these attackers will leave the evidence and will be held accountable by our service and in reality the condition or situation is much more complex than that some notes have very poor network connectivity so they may vote for this work block once and then later they see another longer chain and vote for another block but our service will not have them

accountable because they just suffer from poor Network but if any attacker that is on purpose trying to launch such an attack our service is guaranteed to detect them and to slash their stake tokens with uh for So Sophisticated analysis of the whole self conscience protocol and we publish our result in a top Tire academic paper so our forensic monitoring service ensures that the attackers cannot successfully launch an attack unless they control Beyond one third of the

masternodes which means it's 33 note 37 nodes 37 masternodes and if they launch and talks they will lose all the stake tokens of this 37 masternodes we also ensure that attackers must leave a review irrefutable evidence irrefutable means that it attackers cannot say that I am not doing badly I am not doing anniversarial if our service has the evidence then the attacker must misbehavior and their snakes must be slashed

we also ensure that the evidence of the attackers is guaranteed to be discovered by our service that is uh they they may try to hide their evidence they just send the message to a selected small number of other monster nodes but that will not hide their evidence in the end they are misbehaving messages or evidence will be transmitted to our monitoring service and they will be slashed and finally we ensure no honest nodes will be framed that is the evidence we are not forceful forcefully acute any honest Master knows

and showing in this figure is our currently running and live forensic monitoring service on our devnet and you can see that we have the we have launched several toy attacks and our monitoring service cache then we have the the number of the blocks that is affected and how many attackers are involved in this attack and so on okay so lastly I will introduce our scaling solution namely the xdc subnet so by starting a subnet you can scale

your performance for example for each different application you start your subnet and the subnet only runs one application so it's much faster than the main net that runs multiple applications but beyond that we have other motivations that is a privacy security and sovereignty so for privacy it is that some customers for example the some Enterprise customers they do not want the transactions on blockchain or The Ledger to be disclosed to the public and for security is that the customer

also wants to harness the security level of the mainnet because main end is much more secure than the subnet as for sovereignty it means that the subnet should be a standalone uh blockchain this means without the mainnet the subnet should work fine with itself and the thumbnet should be customizable for xdc it means that the parameters can be changed for example how much reward the master nodes get and what are the initial number of masternodes such something like that so the customer wants to wholly own this subnet

so we have our Sunday design as follows so our approach to ensure security is security via checkpointing the sub subnet owner deploys a smart contract on the mainnet and the thumbnail headers are checkpointed or uploaded to the smart contract and in this way we can harness the main security level I will go into more detail and this is our detailed architecture first the customers can run a sovereign blockchain and it is powered by xdc 2.0 protocol which is uh highly efficient

and it is also compatible with all the HTC tools and of course FTC blockchain is evm compatible so it supports native em smart contract what is more important is that the account format or the address format for subnets and the mainnet is the same which means that you only need one private key or account to work with multiple thumbnails and mainnet this is what interoperability means so we have this subnet here and we have the main ad which we have a smart converted product in the minute it's for

the checkpointing reason and we have the relayer the trustless relayer who is in charge of uploading the subnet headers to the minute so the relayer listen to the subnet header and encode the header and upload them to the main and smart contract the uploading is through the transaction so the relayer has to pay the fee but the XTC Cassie is quite low it's not a big deal and the release is trustless this means that anyone can be a relayer and there may be some adversary layer who uploads some invalid header but it's

it is okay because our smart contract will validate the header first and then store the valid ones and just ignore the invalid headers and to harness the security level of both the subnet and the minute we have our wallet plus so our wallet Plus is a wallet for the subnet just like a normal wallet it can submit and confirm subnet transactions what is more it can interact with the FTC Mainland through API it can query that whether the subnet block header is uploaded to the minute

and whether it is finalized what is the finalization status of that so after confirming that transaction or the header that contains the transaction the block that contains the transaction is finalized in the subnet and also uploaded to the mainnet our wallet plus can provide extra security for a transaction confirmation so let's make a comparison to the other scaling Solutions so for each room we have many layer 2

Solutions for example optimistic robot take a robot I believe these two are the leading ones and our launch has launched their subnet design as well and xdc well we have our subnet tool so the hour launch approach is that their model is that the a subset of the Mainland validators will be the subnets validators in contrast in HTC any customers any nodes can be the subnets validators and our model is that the subnet will be checkpointed on the mainnet

as for scalability all the solutions are quite good for the security level the ethereum layer 2 Solutions they have only the maintenance level as far as I know that no ethereum Solutions says anything about their layer 2 security as for the Avalanche the security level is only the subnet level which means that the do not resort to the security level of the main net for FTC we have both the mainnet and the subnet security level

for the security approach the ethereum layer 2 have fraud proof for optimistic grow up CK proof for JK row UPS and for the data availability problem they have data availability proof and recently there is this restaking mechanism that is used for data availability proof Avalanche requires the validators to meet certain requirements to be in subnet such as the validator should be all located in one country or they should have some

some certain of a certain level of network connectivity for xdc our security approach is that the mainnet keeps an immutable version of the subnet header chain in the smart contract the smart contract will also validate the headers when they receive them and all these solutions they are evm compatible and that is good as for interoperability which means whether the users can use one account to interact with multiple chains for ethernet layer 2 it depends it depends on whether the solution use the same account model with the Israel

mainnet and for Avalanche and xdc it is good we have interpretability for privacy ethereum layer 2 Solutions it also depends some solutions does not disclose or upload the full transaction data to the main end but some choose to upload the full data and for our launch and xdc the subnet data is keep inside the subnet is never uploaded to the minute only the header is so we have privacy as for sovereignty is related to it also depends

as far as I know all the layer 2 solutions they run their own layer 2 Network maybe it's not a network maybe it's just a single node so there's no sovereignty in them and for our launch to be a subnet validator you have to be the main end validator first so I can say they have only partial sovereignty as for xdc 2.0 uh we have a fully or wholly owned subnet which means we have fully sovereignty and one can run the subnet and the subnet is Standalone from the mainland even the mainland crash down

which could never happen I guess your subnet will continue to work so to summarize xdc 2.0 provide you another choice for UAM compatible or UVM based the apps and its advantages include the state of the art consensus engine which is secure and efficient and it has the unique and crucial forensic monitoring ensures that attacking nodes will be slashed and we have theoretical guarantee for that and our scaling Solutions subnet it is Sovereign scalable customizable and

interoperable so thank you and this is all for my talk and welcome to follow us on Twitter and visit our downforum xdc.dev thank you [Applause] check there we go uh so if we have any questions for Gary raise your hand yeah great speak loud please hey the name is Alex thank you very much for your presentation quite interesting uh I cannot hear you oh sorry no it should be better though I can hear myself a bit to laugh so the

question is you said you have an immature headers or any case of Subnet in validator which means that in in a sense I can produce amount of subnets and overload the cost of having a validator or how exactly the archiving in storing process happening seems to be exploitable uh sorry can you repeat your question I did not hear it clearly oh apologize I mean you said in sense of security validator has to have immature headers uh of the contract I missed that part actually or uh the checkpoint yes the

main the maintenance Mark contract that checkpoints the subnet headers yes so if you if someone will want to ex abuse your main net he can create repeatedly and must subnets and validators has to store it and this way uh I do not know do you have ways to Archive overloads of this step what will happens with the mainnet yes I uh let me try to rephrase your question in my understanding thank you for a question uh in my understanding you're saying that what if someone tries to upload like spam or Garbage data

to the mainnet not not exactly I mean uh you while you're creating subnet create an immature header that has to be stored and you can spam by creating of subnets that my net and overload it that's my question can can you handle it and what exactly will happen in if the case uh yes so firstly the xdc network the mainnet it's it's a capacity or its ability to support transactions is quite high and currently the traffic is not that high so to push the traffic on Main

ad to the to go beyond its capacity I think it's quite uh it takes quite a lot of maybe powers to do that and uh also I think in ethereum it's uh it's kind of like an unavoidable problem that is some transactions is not useful at all or it is it can run some smart contract but it it is meaningless something like that I think it is unavoidable in any ethereum compatible blockchains in most cases I believe yes but in case of

Bitcoin notes we know already you have to have a terabyte or of bites in order to maintain it and the process is infinite if you have no mechanism to store it then after 10 years probably it will be tremendously overloaded uh yes but um yeah in the 10-year scale maybe the data is large I have not done the calculation but I want to say that we only upload the header data which does not include the transaction payload so which the header is this means the header is much smaller than the

the whole block data that includes payloads and also the data like data growing or data explosion problem is also some some problem that's existing many other blockchains and actually the I know each room has something some solutions tries to solve them such as prototype charting something like that I see thank you very much thank you yeah give them a round of applause thank you for for Gary please thank you thank you Gary