On the 6th of May 2021 we welcomed the founders of Notoros DLT, Andrew Brick and Brendan Laiben, into the Radix Telegram for a live and in-depth Q&A session. 

Andrew and Brendan stayed long after the Q&A officially ended, answering questions and interacting with the Radix community which was greatly appreciated. We have included their answers in full below.

You can follow Notoros on Twitter for further updates.

Could you first introduce yourselves to our community?

Hello Radix Community! We are Brendan Laiben and Andrew Brick, the co-founders of Notoros.

We’ve both worked in the blockchain space for nearly a decade, for startups and enterprise, and at all parts of the technology stack. Brendan started in the industry at a Bitcoin miner hosting/reselling startup, where he used his mechanical and aerospace degrees to manage the power distribution, cooling, and physical infrastructure at the mining datacenter.

Brendan was one of the first miners on the Ethereum chain, and has been auditing and developing smart contracts professionally since 2016. Andrew, a longtime Bitcoin enthusiast, and hobbyist crypto writer, started developing smart contracts with friends the summer before getting his Master’s in electrical engineering.

As a result of our rather unconventional educational backgrounds, we approached the crypto space with a different outlook on what was working, and what was not. When we discovered Radix we immediately understood their team, like us, had a different outlook on consensus and the needs of the industry. Notoros was inspired by Radix’s use of logical clocks and sharding and began as an effort to bring that insight to a wider developer audience.

Can you go into what Notoros is all about in detail? What problems inspired you to create Notoros?

Sure! After years working in the space, we were tired of telling clients they had to downsize their ambitions for their dApps because the technology was simply not scalable enough, or the functionality they wanted was limited to certain tools or platforms. Because Radix solved the scalability part, we felt we should bring the rest of the developer ecosystem along.

Combining the logical clocks from Tempo with transaction ordering and lazy execution enabled us to distribute and parallelize the functionality of any virtual machine over a sharded distributed system. What this means is, we have made the logic behind virtual machines into a *protocol* that operates at Layer-1, as an independent execution environment. It’s like having ‘alternate dimension’ ledgers that coexist in the same consensus space.

Can you share with us some of your recent progress? And can you please share any future plans for Notoros?

A couple months ago we released our whitepaper, and we were recently chosen as a Radix Betanet validator! (Our validator address is vb1q0fnvhpaucn8k8ddhyjr39r2el0js2md5vr5m9tzlh5g4ylncw5d2y3tfus).

Our betanet integration is coming soon. We had to delay the release due to the abundance of new code in the Radix Betanet repo and a lack of development time from meeting with investors.

We are in the process of submitting a PR to the Radix codebase, which will lay the groundwork for Notoros functionality. Once the PR is accepted, the Radix validators will have to update their nodes. We will keep the community updated with our progress as time permits.

‍

OK, let’s move to the next segment - Questions collected from the community!

‍

Why should I choose Notoros over eth smart contracts ?

This is an awesome question!

Notoros provides all of the functionality of Ethereum, so at a baseline they are the same. But Notoros also includes a whole host of features designed for decentralized application development and industry adoption.

For example, in vanilla Ethereum your transaction is subject to front-running attacks: other users can submit transactions before yours that substantially alter the effects of your transaction. Think about how that can impact an exchange’s operations. With Notoros, you specify the state dependencies that your transaction operates on, so your transaction always executes exactly as intended.

Another example is how Notoros can combine multiple types of VM actions into a single operation. You can specify an ERC20 transaction in a public Ethereum VM that executes at the same time as an NFT transfer in an encrypted Ethereum VM. Since the VMs are decoupled from the core network, applications can retain their privacy while still having publicly validated transactions.

Will there be interoperability between the Notoros EVM and the Radix Engine (based on Scrypto) later? Especially regarding token transfers, but also the composability of smart contracts/components.

It is possible for any Notoros VM to be made aware of any Radix Engine actions in the same transaction. In fact, Notoros is implemented in Radix through the Radix Engine. However, this is a one-way relationship: the Notoros VM does not feed back into the Radix Engine.

How do you see the relationship between Notoros VM and the future Radix Engine, since Scrypto will be much safer to use and faster & easier to develop compared to Solidity - an overall better development experience. Is Notoros VM more targeted at migrating existing "legacy" dapps, than developing new projects?

Good question.

Ethereum and Solidity are just the first integrations for Notoros. We started there because the Ethereum developer community is the largest in the blockchain industry by a factor of four, and all software adoption starts with developer adoption.

As dApp developers ourselves, we have a long list of projects that were simply impossible to build on other networks. Notoros is designed for any type of decentralized use case, opening the door for those projects.

We see Notoros like HTTP for Radix. Some developers are working close to the metal and thus use lower-level lower protocols than HTTP (i.e. Radix Engine / Scrypto). However, the vast majority of developers are building applications that need the abstractions available in Notoros. Both types are needed for the ecosystem to flourish.

Will the Notoros dApps be running as a layer 2 network on top of the Radix Network, thus requiring the XRD system tokens for transactions? If not then how does the Radix Network benefit from the Notoros dApps?

All of the transactions that are processed by Notoros dApps must first be processed by the Radix ledger, and thus users have to pay XRD fees.

We think of it more as a "layer-1.5".

Within a Notoros VM, there may be any kind of rules regarding whether the transaction is valid for further processing of application state once it is accepted by Radix. A simple VM may process any transaction that has been recorded to the ledger, while a more complicated one may only process transactions that were sent by an account that holds a stake in another VM. The community may decide to support a VM implementation that requires XRD to be burned or staked to process a transaction. This flexibility gives developers broad control over their applications while keeping them all on the same, fully composable network.

How do you plan to get adoption for Notoros in the crypto arena?

Ethereum has plenty of adoption already in the general crypto arena: bringing that community in will be a simple matter of showing how great Radix and Notoros are in comparison to regular Ethereum. Long term, we know that the adoption within the consumer market will drive the crypto market to the network, so we are focused on bringing real value to industries like energy, supply chain, medical, and IoT that are underserved by existing blockchains. Each of those industries have massive corresponding financial systems that can be brought into the Notoros ecosystem.

Did you think about airdropping tokens to Radix main net stakers? Similar to how projects in the LUNA ecosystem airdrop tokens to LUNA stakers?

We have considered a lot of ways of getting tokens to Radix users. After all, you will need to pay your transaction fees in XRD to send Notoros transactions, so the people holding and staking XRD are going to be the first people that can use Notoros. Since we can run multiple types of virtual machines on the same network (similar to how colored coins work), we can have multiple tokenomics systems. This also means that we can experiment with a bunch of different models to find the best one. It’s complicated, and we want to make sure it’s right, so nothing is set in stone right now.

What is the plan for engaging support of current eXRD token holders, e.g. airdrops to Radix holders?

We are considering a variety of ways to engage eXRD holders, from airdrops to NFT rewards to premium access. All of our plans are still up in the air at this time, but we promise to make it exciting for everyone!

Will Notoros's Betanet connect with Radix's Betanet for testing?

We will be integrating Notoros functionality directly into the Radix Betanet. We will be submitting a PR to the Radix GitHub that will include the code needed for the network to validate Notoros transactions. Once the PR is merged and enough validators have updated their code, anyone will be able to use Notoros on the Betanet.

Will Notoros run on the Radix network (betanet / mainnet) or as an independent network using Cerberus?

Notoros will run on all of the public Radix networks. As part of our Blockchain-as-a-Service business, we also offer private consortium networks that are streamlined for Notoros.

Are you bringing a DEX/AMM to Radix's Olympia release?

We are not, though any existing Ethereum DEX/AMM will work on Radix through Notoros (looking at Bancor and 0x).

Does Notorus use maybe undocumented, but public Radix network features which anyone else could use in the future to build another VM on top of Radix?

Everything that we use from Radix comes directly from their public repositories on GitHub. While it is certainly possible to build more VMs directly into Radix, it will be much easier, faster, and cheaper to build them on top of Notoros.

Assuming Notoros runs on top of Radix, would it be basically an alternative to the Radix Engine (both accessing the core network)?

Notoros uses the Radix Engine to enforce the Create/Read/Update policies in each transaction. It is not a replacement for the Radix Engine, but can be used to create applications that take advantage of the functionality within the Radix Engine and the Radix network.

How and what do you use from the earlier Radix Tempo components? Looks like a solution to Dan's old problem? Using Cerberus as consensus and all other things from Tempo?

We were heavily inspired by Tempo’s use of logical clock counters to create a unified understanding of the network state. We applied that concept to sharding Ethereum, and then molded it to work with Cerberus. Notoros is the second evolution of that original Ethereum-specific integration, generalized to work for any VM.

Will the Notoros VM be limited by the throughput of the Radix network, like 50 TPS with Olympia mainnet?

Notoros operates exactly as fast as consensus: for the public mainnet launch, it will be limited to the full speed of that network. Rollups, Layer 2, and other scalability options can artificially increase the volume of “transactions”, but for purists like us the core network rate is the real metric. For our private Blockchain-as-a-Service offering, we also have a streamlined version of Cerberus designed for consortium networks that is able to reach over 24K TPS.

With our experience operating Cerberus privately, we have been able to glimpse its capabilities. We are fully confident that Radix’s public implementation of Cerberus will scale rapidly beyond the scope of what other chains even dream of while still maintaining full atomic composability. Olympia may be only 50 TPS at launch, but we know we will never need to worry about scale again.

I read about fundraising in your recent tweet, is that something you guys can comment on? Can the community participate in it?

We are currently raising a private equity round from qualified US-based investors to fund the Blockchain-as-a-Service arm of Notoros (think Infura / Alchemy / Consensys ) and support additional development on the Notoros software. If you are a qualified investor and would like to participate in this round, please contact partners@notoros.io. 

In the future, we expect to have multiple opportunities for the general public to participate in token sales. It is our goal to bring blockchain technology to the entire world, and the many tools needed to do that will need to be decentralized first. Systems of tokenomics will play a large role in the future economy.

Open chat questions from the community.

Why was Noether rebranded to Notoros?

Noether was rebranded to Notoros to avoid an unfortunate branding conflict with another organization in the space. We created Notoros because we felt that while Emmy Noether's work was earth-changing, and in many ways an inspiration for our technology, this system deserved its own name. Notoros is from "Noether-OS"

We will always use Emmy's work as inspiration.

Are there any Eth dapps which are already in the pipeline for migration?

This is in development. Some dApps cannot be migrated until after Betanet.

Right now we are mostly working with smaller companies who have wanted to get into the blockchain/dApp space for a while but could not find a platform that suited their needs

We are excited to help migrate Eth dApps to the Radix ecosystem, and at the same time, we are working to expand the number of organizations that are looking to develop dApps in the first place.

Could Notoros fix Eth scaling issues?

Notoros does fix Eth scaling issues, just not on Ethereum mainnet.

Notoros offers the "pure" scalable layer-1 development environment so many Eth developers, including ourselves, have crazed for since we first got into the industry.

Is parallelization dependent on the way smart contracts are constructed? Or does any smart contract / VM allow itself to be parallelized by your protocol? I'm thinking shared state in some of the smart contracts out there. Or does it allow for it but with risks involved (race conditions, ...)

Parallelization is a property of the way that transactions are constructed for submission to the Radix ledger. The VM specification decides what resources are indicated by the boundaries in the transaction. Since each transaction explicitly specifies its dependencies in read/write boundaries, we are able to retrieve the necessary pre-state and process the outcome in parallel without worrying about conflicts.

Does Notoros' sharding retain atomicity across shards if it were to be implemented as a standalone network?

Yes, cross-shard atomicity is built in with the protocol. It is also possible for multiple networks to be merged atomically if the conditions are correct.

____________________________________________________________________________
‍

Thank you Andrew and Brenden for being here today. We appreciate your time here with us, and hope to have you back on another round - maybe via video next time! Best of luck with your Betanet, your validator node running, as well as your private equity round! Hope to see you around the Radix Community as much as possible:)

To stay up to date or learn more about Notoros please follow the links below.

Website: https://www.notoros.io/

Whitepaper: Link 

Twitter: https://twitter.com/NotorosDLT

Reddit: https://www.reddit.com/r/Notoros/

LinkedIn: https://www.linkedin.com/company/notorosdlt