More pack content.

No. Good questions, disappointingly ambiguous answers. The matter is a nice rabbithole for us to delve in and further explore.

:)

Yeah, but they pay taxes so I guess they look at it differently.

They aren't, but pulling out funds is very expensive. There's a pretty interesting trade off between putting assets in a company or keeping them private. In most situations, you'd rather pay the "wealth" tax.

ERC1400? That's still transparent and comes with issues of its own.

Ive got a couple: - What motivated you to join Dusk? And how are you liking it? - How does your day to day activity look like? - How closely is your work related to on going development activity? Is it for future network features or is it a mixture of helping out on existing implementation questions as well? - What's your favorite type of maths? - If I wanted to join Dusk as a cryptographer, what would your advice be in terms of prerequisites? - Which current developments in the fields of cryptography and mathematics excite you the most?

There are so many attack vectors, from supply chain attacks to gaining internal intel and abusing that to getting access to DNS information and redirecting websites.

Resilience testing?

They are. Dusk has its own VM that is not EVM compatible/equivalent. Nor is Dusk a L2 to Ethereum, like the others are. Smart contracts in Dusk are compiled to WASM.

Decentralized and permissionless network =/= smart contracts having no authorization mechanisms and an owner that has more control than other users.

No. A standard is just a set of rules. If you look at ERC20 for instance, it has a transfer function. If you implement the standard it should accept an address and a value. The address you pass in should get the amount of tokens based on the value you pass along. If you want to comply to the standard, you implement it that way. But, you don't have to. Nor is there any real way to enforce it. That's the choice of the implementor. Having a reference implementation is sort of like a template, where you can make your own changes if you require so. Reference implementations take away some of the ambiguity a standard can have. (There is some in ERC20 that have caused a lot of issues to third parties that build services around them)

I would assume not, unless it's a token contract factory or the native token implementation relies on it as well. Normally a standard just sets out the interface that implementations have to rely on so It's easier for third parties to interact with solutions that are comparable. ERC20 for instance is a standard for a fungible tokens on Ethereum, and there are many implementations available. Most well known implementations for a good number of standards is provided by OpenZeppelin. From what I gather, Dusk will provide, at the very least, XC and XSC as standards that come with an implementation. Probably XNFTs as well. I'll leave it up to @autholykos to confirm that. ;p

You mean for the Dusk native token itself? XC is supposed to be Dusks ERC20 equivalent, a ready made standard for others to use as well.

I hadn't seen it, but this shouldn't be too surprising? Like @smith1517 said, the primitive itself is safe. Implementing this type of complex software can introduce serious security problems though if done wrong or certain edge cases aren't accounted for. One of the examples given in the paper is about data encoding of integers leaking information if there are many-to-one parties involved. Another encoder they used (within this given library, SEAL) doesn't have information leakage and could be used to circumvent the issue above. If you have complex algorithms and software, bugs will exist. If you wire together complex libraries that work on certain assumptions, test if they still hold up and guarantee the security boundaries you initially setup. It can always happen that a specific implementation of software has a vulnerability (like Dusks Plonk had), what is important is how easy is it to fix that vulnerability? I guess one of the main criticisms of TEEs is that, due to depending on third party hardware and libraries, mitigation or patches have a much longer lead time (on average) than if you have an issue in your own code base.

On the Dusk Network testnet, not the one on Ethereum.

No comment

Not high, but who knows? ???? Almost everyone is still in a very early experimental phase. Only China seems to be pretty far ahead with their e-CNY plans, as they're even in public testing right now.

If the DLT has a virtual machine/scripting language/computation engine attached to it, it allows for the financial asset to be programmed against in a much more structured way versus programming money with existing infrastructure. It's a huge advantage the current system doesn't provide plus the tooling to do it is mostly already out there, albeit not in a performant and privacy preserving way.

The project I currently work for is doing trials with Norways central bank.

It could be like Makers POA chain? We discussed a hypothetical, very dumb bridge in here before. Once they set up a CBDC, even on their own network, it will be very hard to prevent some form of bridging/IOUs on other chains to be setup.

Yes and yes

Sure, but one would assume they're pretty due diligent on every aspect they're analyzing. And the analysis they do is trail/phases based. Stage one didn't seem to target smart contracts itself.

A custom one that has ZKPs as a primitive in the VM and a VM that is fully fledged? Not really no, would have to do some more research on that. Most build upon an existing solution. Something like MINA does have its own VM, but it's a simple VM, comparable to what Bitcoin has with their scripts.

It's locked and reissued on Binance Smart chain.

He probably knows what you know.

Nice

Would this be one of those Windows loading bars?

Might be equivalent to chip design, where ML/AI helps in some cases but bespoke modeling is still the way to go for some critical, optimized circuits?

CBDC would be a holy grail in a way. ;p

"If many contracts or users have to access the state of one output, It creates a race to be the first to spend that UTXO & there can only be one winner" I might be wrong here, but this sounds more like an issue that can be somewhat resolved in a naive way. If you can introspect what notes are already available in the mempool or (if you're just thinking single user) if a client side transaction signer checks which notes are being attempted to spend, this should be mitigated for a large part. Given that Cardano has a high time to finality, It'll be much harder to make assumptions for the former. (5-10 minute finality) While the latter doesn't necessary solve multiple smart contracts accessing the same note. On contract state management through the account model (Like Dusk wants to do with Zedger), should in theory be able to mitigate some of the pains for certain use cases where that model is more efficient. I'll have to check out how FuelVM prevents some of Cardanos issues, if they are even able to do so.

If you want to check out a successful UTXO based VM, checkout FuelVM. Ethereum L2 rollup with UTXO and a Rust-based language (Sway).

Key question

Has been there for a long while now IIRC.

I don't think you should stare blind at the CBDC use case. CBDCs can be implemented in various ways, from big payments for a certain subset of high value intermediary transfers to a full scale retail implementation. A full retail implementation will be inevitable and when it arrives, it'll be bridged and cross-chain in my opinion. Who sets the standard/baseline and educate regulators will be important though.

Hmmm... This is a good question.

It really depends what you include in a given transaction. Block sizes for Ethereum have been growing, allowing you to put more into them. But at the same time, transaction sizes grow as well. TPS as a metric is pretty useless without proper context.

No. In Dusk nodes, the verifier is called the prover service. Each node has, through Rusk, a prover service available. Since the CLI wallet does not run a Dusk node/Rusk instance, there is a cluster of nodes the CLI reaches out now to do the proving for you. Once they start opening up node running for the public, you can just change the prover service address to point to your own node. Ema has talked about trustless delegation of proving as well as something they're working on, which would be a cool feature to have with some very awesome implications.

Nice, have a good time together with the team sir!

No, because Rusk will have different opcodes and the contracts have a different API/DSL.

Rusk is already part of testnet. So... In theory... if you know what you're doing and how to do it, you should be able to deploy smart contracts? I'm not sure if those features are exposed yet on the running nodes and doing it without proper tooling is always going to be painful. ?

You can stake here: https://staking.dusk.network/

Dusk is primarily marketing itself towards TradFi, providing the basic building blocks (privacy and auditability on a public network) to accommodate those use cases. These same building blocks can be used for extending DeFi into the privacy realm as well. xDeFi. It's something other layer 1 networks cannot natively provide.

It's only a frontend bug. They're working on it. :)

Yes, and that's pretty cool actually.

Probably an issue at their end. As far as I know this endpoint should give the correct circulating supply: https://supply.dusk.network/

The only form of real interoperability that is currently out there are cross-chain NFT marketplaces. The NFT market is still very experimental, with currently a large focus on 'art'. NFTs are going to be huge once you're able to map them to more 'tangible' assets like real estate. Partial ownership of assets is a huge, yet relatively unexplored market.

Svelte has a built in state/store management functionality. https://svelte.dev/tutorial/writable-stores You can also use event dispatching as a way to pass state around, depending on the situation/use case of course: https://svelte.dev/tutorial/event-forwarding

It is a compiler with some pretty neat features, so I would say it is more than a templating engine. But there's nothing stopping you from integrating it into some backend framework and using it as such.

I'm not sure how familiar you are with frontend (presentation) web frameworks. Svelte/Sapper is a competitor to React/Angular/Vue. It takes a different approach than the three I mentioned. Not to get too technical but.... (Gets technical) Web development often deals with reactive interactions. You click something and as a result, something happens. Websites have a DOM (document object model) that functions as a programming interface to interact with web pages. Due to the interactive/asynchronous nature of the web, these interactions can quickly mess up a pages structure. This is why old libraries like jQuery got out of favor for complex apps and React/Vue/Angular became popular. React/Vue/Angular make use of a virtual DOM. If this VDOM changes, React/Vue/Angular update the changes in the actual DOM to achieve consistency. The disadvantage of this approach however is that your web app needs a lot of library code to do the difference checking and extra computation. Svelte takes an entirely different approach. It's a compiler that directly links interface interactions with the code you write. (real reactivity) It's a lot faster and you don't need to import a whole library into your app. Svelte has been my go to tool for a lot of projects lately.