S2E23 | Transcript

Roman: [00:00:03] Yes. Hello, everyone, and welcome to the Weekly News Digest. And we're happy to share with you the progress of the past week and today with you are Roman, Serge and Mike.

Mike and Serge: [00:00:16] Hello, everyone.

Roman: [00:00:20] As another short reminder, you can ask your questions via Google form, via text chat, or like to ask a question live. Just raise your hand and we will let you ask a question and the recording will be available in a couple of hours. And let's get started.

And first, news about the BIT network and the UI EnexSpace updates. And in previous episodes, Serge indicated the presence of a problem in the validator. And as it turned out, that problem was related to parsing of the data field. So, Serge, please tell us more about it.

Serge: [00:01:06] Yeah. So. It was an deploying error and we fix it. It was not a big deal. But what really matters that our user interface website were not able to handle this error. So this is the point where we made fixes and made UI significantly more stable. So moving on.

Roman: [00:01:49] Yes. Let's move on and let's move on to the update in Smart contracts on BIT network. So please, couple of words about it.

Serge: [00:01:59] So currently BITnetwork is under one more update. And also all Ethereum based contracts for space bridge test environment are also updated. So we're enabling the whole bridge from scratch. So your all the may be unclaimed transfers in these test networks. They were not be useful anymore. But you can make new tests on the latest version. And the idea of this update. On one hand, we improved error handling in all smart contracts. This is useful for future dapps integration and for our own purpose to understand what happens in case of some issues. And on the other hand, we just making one more test like integration test of the of the whole process of enabling start starting space bridge with transferring ENX and the starting station part of the ENEX dex. But so currently their update of the BIT is done. But the bridge is not enabled yet. Not started. And that is why currently BIT network is still not available, but it will be today possible to continue tests.

Roman: [00:04:09] Yeah. Thank you, Serge. And let's move to the next news. And it's about a future BIT merge of the BITtest network functionality to the Pulse Network. And please tell us details about it.

Serge: [00:04:31] Yeah. So since the last week, we. Repaired special wrapping of our changes to create a correct fork to pull mainnet. And to allow seamless synchronization of future nodes of current POS nodes to allow them seamlessly go through fork block and without any desync errors. So these preparations are ready. Now we need only to test the bridge on the copy of Pulse Network just to be sure that not only in BIT and in BIT network everything goes well, but also on exact blocks of Pulse network because it has a different history with own fork history. So it requires additional tests.

Roman: [00:06:03] Moved to the last news and it's about the vote we launched just yesterday, and it's a vote about the SB prefixes for tokens passed through the bridge and destination networks. And we decided to tell you more about it because it's not as simple as it seems to be. And it's a BIT of a complicated question. So please tell us more about these prefixes.

Serge: [00:06:37] Yeah. So I think there are three, three points of view. Possible points of view. And I will describe like pros and cons for them. So first of all, these changes do not require any effort from development or testing team. It is very simple change. So if someone makes a decision based on let's do not change anything just to save more time to bring release earlier. It is not the case. So that's the first thing. Uh, second, why it is interesting to preserve the same name across various networks. Because in that case, Space Bridge allows token issuers on some decentralized apps teams to create tokens in several networks, like with one token issue, for example, you can create a token in Enecuum via a mobile application and then make a bridge of this token, for example, to Ethereum and trade this token at Uniswap, for example. And the token will preserve its name and it will be easier for a community of that token to explain that it is the same token but in other network and to promote such token. So. It is for the preserving name. But there are also points against this change to make clear in the name of wrapped tokens.

Serge: [00:08:59] Tokens that were created by bridge validators that they are not owned by initial token owners. So just to distinguish who is in charge of the emission of the token, because it may be unclear for users, for community of such created tokens that validators are in charge and responsible for the emission of this token. So for some users, it might not be a big deal, not an issue, but for some investors it would be not might be not desirable because it is a case of distributed responsibility for the token supply. So maybe they prefer that initial token owner creator has the full responsibility of its supply. Like, for example, tether company and Usdt token it has own. It is issued in each network by tether itself, not via any third party. So it is the point to clearly. In state that tokens are made by bridge validators, not by initial token owner. I guess this is. All of these may be my explanation will bring more questions and I will be happy to answer them. For now, that is all.

Roman: [00:11:03] Thank you, Serge. And today with us, Mike and Mike, please tell us a couple of good words.

Mike: [00:11:12] Yeah. So last time I was on our meeting a few weeks ago and our plan was delivered to the one week, so it's already a few weeks gone, but we are still under the process of deploying the contract. So let's wait until a few moments. Then we finally will deliver the bridge. And the users will be able to use the bridge between few EVM chains and Enecuum. We're in the final stages!