Skip to content

Update naming (DuskDS, execution environments...) #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added src/assets/modular_vs_monolithic.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
6 changes: 3 additions & 3 deletions src/content/docs/developer/integrations/exchanges.md
Original file line number Diff line number Diff line change
Expand Up @@ -111,15 +111,15 @@ Dusk is **fully compliant** with key global regulatory frameworks, providing rob
- TFR (Transfer of Funds Regulation)

Dusk supports two distinct transaction models, which users can navigate between in a transparent way:
- [Phoenix](/learn/tx-models#phoenix) enables confidential transactions while maintaining regulatory compliance
- [Moonlight](/learn/tx-models#moonlight) is a completely transparent and auditable model.
- [Phoenix](/learn/deep-dive/transaction_models/tx-models#phoenix) enables confidential transactions while maintaining regulatory compliance
- [Moonlight](/learn/deep-dive/transaction_models/tx-models#moonlight) is a completely transparent and auditable model.

Unlike traditional privacy coins, Dusk doesn't aim for full anonymity, but instead provides both privacy and regulatory compliance.


### Compliance in Moonlight (public)

[Moonlight](/learn/tx-models#moonlight) is designed specifically for full transaction transparency, making it ideal for integration with exchanges and ensuring that:
[Moonlight](/learn/deep-dive/transaction_models/tx-models#moonlight) is designed specifically for full transaction transparency, making it ideal for integration with exchanges and ensuring that:

- **CASPs** can easily meet compliance obligations under **AMLD5**, **MiCA**, and **TFR**.
- There is full support for **KYC**, transaction monitoring, and reporting requirements without any legal or technical barriers.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The GraphQL API provides access to finalized historical blockchain transaction-e
The **moonlightHistory** endpoint allows for advanced filtering, enabling queries based on sender, receiver, block range, and pagination.**fullMoonlightHistory** retrieves all public `DUSK` value transfers for a given address, without additional filtering options.
:::

You can also checkout the [transaction models](/learn/tx-models#transaction-models-on-dusk) page, to get familiar with the terminology of `moonlight` & `phoenix`.
You can also checkout the [transaction models](/learn/deep-dive/transaction_models/tx-models#transaction-models-on-dusk) page, to get familiar with the terminology of `moonlight` & `phoenix`.

Refer to [GraphQL queries](/developer/integrations/http-api/#graphql-queries) for additional information on the GraphQL endpoint.

Expand Down
4 changes: 2 additions & 2 deletions src/content/docs/developer/smart-contract/core-concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ Because the **core** crate lacks heap memory allocations, we can explicitly also

### Usage of panic & reverting state

While you can have Result types in your smart contracts and handle them in multiple function calls, in the end you may want to abort execution. For example if a specific requirement is not satisfied you can always make use of directives that lead to panic (e.g., `.expect()` or `panic!()`). This is equivalent to `require()` in Solidity. It will abort the smart contract execution and let the transaction [fail](/learn/tx-fees#unsuccessful-transactions). This will also **revert** the state, making no changes to it.
While you can have Result types in your smart contracts and handle them in multiple function calls, in the end you may want to abort execution. For example if a specific requirement is not satisfied you can always make use of directives that lead to panic (e.g., `.expect()` or `panic!()`). This is equivalent to `require()` in Solidity. It will abort the smart contract execution and let the transaction [fail](/learn/deep-dive/tx-fees#unsuccessful-transactions). This will also **revert** the state, making no changes to it.

## UTXO & Account-model

Expand All @@ -58,7 +58,7 @@ Therefore developers need to figure out how to represent users.

In Dusk, an "address" is defined by the developer within the contract's logic. This approach gives developers more control over the privacy and compliance features of their applications but also increases their responsibility to securely identify and authenticate users and transactions.

The `msg.sender` is not "abstracted" away on dusk. A way to mimic that behavior is by explicitly taking the address as function argument and a signature that signed all other function arguments (including the address). Then verifying this in the function. Examples of such usage can be found in the [transparent token standard](/learn/token-standards#dusks-token-standards), the [Moonlight transaction model](/learn/deep-dive/transaction_models/moonlight) and [Zedger](/learn/deep-dive/transaction_models/zedger).
The `msg.sender` is not "abstracted" away on dusk. A way to mimic that behavior is by explicitly taking the address as function argument and a signature that signed all other function arguments (including the address). Then verifying this in the function. Examples of such usage can be found in the [transparent token standard](/learn/deep-dive/token-standards#dusks-token-standards), the [Moonlight transaction model](/learn/deep-dive/transaction_models/moonlight) and [Zedger](/learn/deep-dive/transaction_models/zedger).

## Methods

Expand Down
4 changes: 2 additions & 2 deletions src/content/docs/learn/block-explorer.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ description: Use the Dusk’s block explorer for looking at transaction details.

Transactions can be viewed on the <a href="https://explorer.dusk.network/" target="_blank">Dusk Block Explorer</a>, along with statistics and information about the network.

Dusk is a privacy-preserving blockchain. Privacy-preserving [Phoenix](/learn/tx-models#phoenix) transactions do not expose the sender, receiver and amount transferred to anyone other than the involved parties (sender, receiver, and users with the view key).
Dusk is a privacy-preserving blockchain. Privacy-preserving [Phoenix](/learn/deep-dive/transaction_models/tx-models#phoenix) transactions do not expose the sender, receiver and amount transferred to anyone other than the involved parties (sender, receiver, and users with the view key).

For public [Moonlight](/learn/tx-models#moonlight) transactions or other types of chain interactions, the visibility of transaction details depends on the contract implementation and whether developers use privacy technology like zero-knowledge proofs.
For public [Moonlight](/learn/deep-dive/transaction_models/tx-models#moonlight) transactions or other types of chain interactions, the visibility of transaction details depends on the contract implementation and whether developers use privacy technology like zero-knowledge proofs.

The block explorer can be used to view the type of transactions submitted, as well as the payload, transaction fee and gas used.
Loading