mirror of
https://github.com/sonr-io/sonr.git
synced 2026-08-03 18:01:39 +00:00
feature/data persistence (#1180)
- **feat: add documentation and GitHub Actions workflow for publishing documentation** - **docs(concepts): add documentation for chain modules** - **refactor: Simplify session management with SQLite storage and remove deprecated code** - **refactor: Simplify database initialization and remove DatabaseContext** - **refactor: move connection handling logic to resolver package** - **feat: implement session management with database persistence** - **feat: Ensure config directory exists when creating database path** - **feat: Add SetUserHandle function to set user handle in session** - **feat: Add public methods to set session fields with database save** - **refactor: Remove unused session setter functions** - **feat: Add getter methods for all Session Model properties** - **feat: enhance Session model with user name details** - **feat: add Motr support and update UI elements** - **<no value>** - **feat: Add unique handle constraint and method to check handle existence** - **docs: update site URL to onsonr.dev** - **fix: correct import statement for database package** - **test: updated CI to run tests on pull requests and merge groups** - **docs: remove reference to develop branch in workflow** - **feat: add WebAuthn support for user registration** - **fix: correct smart account attenuation preset name** - **feat: add ComputeIssuerDID and ComputeSonrAddr functions to ucan package** - **test: add unit tests for MPC keyset and keyshare** - **feat: introduce new script to streamline GitHub issue creation**
This commit is contained in:
Prad Nukala
@@ -0,0 +1,104 @@
|
||||
## `x/did` - Auth & AuthZ
|
||||
|
||||
> The DID module is responsible for managing the creation and management of DIDs.
|
||||
> Controllers represent on-chain accounts backed by a MPC keypair. Controllers
|
||||
> provide methods for Wallet Account Abstraction (WAA) and are responsible for
|
||||
> managing the creation and management of DIDs for an individual user.
|
||||
|
||||
### Features
|
||||
|
||||
- DID Controllers leverage the Cosmos SDK's `x/accounts` std interface for WAA.
|
||||
- DIDs are represented by a `x/did` controller and are required to state the
|
||||
controller's public key, and which map to the controller's capabilities.
|
||||
- General Sign/Verify methods are provides from the QueryServer for HTTP requests.
|
||||
- The Execute method is used to broadcast transactions across the network. (TODO)
|
||||
- Biscuits are used to authenticate and authorize requests between services. (TODO)
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/did#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/did#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/did#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/did#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/did#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/did#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/did#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/did#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/did#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/macaroon`
|
||||
|
||||
> The macaroon module is responsible for issuing and verifying macaroons. Macaroons
|
||||
> are used to authenticate and authorize requests between services.
|
||||
> Macaroons are requested by NFT Records from [`x/service`](2-‐-Modules-Overview.md#x-service) and granted by controllers from [`x/did`](2-‐-Modules-Overview.md#x/did)
|
||||
|
||||
### Features
|
||||
|
||||
- On Controller creation, a macaroon is created with an admin scope and a default expiry of _315,569,520 blocks (or ~10 years)_.
|
||||
- On Service registration, a macaroon is created with a service scope and a default expiry of _31,556,952 blocks (or ~1 year)_.
|
||||
- Macaroons contain the scope of access for a service and the expiry of the permissions in `blockHeight`.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/macaroon#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/macaroon#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/macaroon#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/macaroon#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/macaroon#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/macaroon#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/macaroon#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/service`
|
||||
|
||||
> The service module is responsible for managing decentralized services. Services
|
||||
> on the Sonr network are essentially on-chain MultiSig wallets that are
|
||||
> represented by a NFT. Service admins are represented by
|
||||
> a [`x/did`](2-‐-Modules-Overview.md#x-did) controller and are required to state
|
||||
> the service's scope of access, and which map to the services' capabilities.
|
||||
|
||||
### Features
|
||||
|
||||
- Needs a Valid Domain with .htaccess file to be whitelisted.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/service#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/service#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/service#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/service#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/service#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/service#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/service#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/service#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/service#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/vault`
|
||||
|
||||
> The vault module is responsible for managing the storage and acccess-control of
|
||||
> Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and
|
||||
> are represented by a [`x/did`](2-‐-Modules-Overview.md#x-did) controller.
|
||||
|
||||
### Features
|
||||
|
||||
- Vaults can be created by anyone, but efforts are made to restrict 1 per user.
|
||||
- Vaults are stored in IPFS and when claimed, the bech32 Sonr Address is pinned to IPFS.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/vault#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/vault#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/vault#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/vault#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/vault#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/vault#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/vault#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/vault#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/vault#appendix)
|
||||
@@ -0,0 +1,170 @@
|
||||
# Consumer Chain Launch Process
|
||||
|
||||
This guide is intended for consumer chain teams that are looking to be onboarded on to the Interchain Security testnet.
|
||||
|
||||
## Interchain Security Testnet Overview
|
||||
|
||||
- The Interchain Security (ICS) testnet is to be used to launch and test consumer chains. We recommend consumer chains to launch on the testnet before launching on the mainnet.
|
||||
- All information about the ICS testnet is available in this [repository](https://github.com/cosmos/testnets/tree/master/interchain-security).
|
||||
- The testnet coordinators (Hypha) have majority voting power in the ICS testnet. This means we need to work with you to bring your chain live and also to successfully pass any governance proposals you make.
|
||||
|
||||
## Chain Onboarding Process
|
||||
|
||||
For teams looking to join the ICS testnet, the onboarding process can be broken down in four phases:
|
||||
|
||||
- Testing and Integration
|
||||
- Planning with Testnet Coordinators
|
||||
- Proposal Submission
|
||||
- Chain Launch
|
||||
|
||||
### Local Testing and Integration
|
||||
|
||||
During this phase, your team will run integration tests with the following elements of an Interchain Security testnet:
|
||||
|
||||
- Gaia provider chain
|
||||
- Visit the provider chain [page](./provider/) for details on which Gaia version is currently being used.
|
||||
- Relayers
|
||||
- You will be responsible for running the relayer that relays the first set of Validator Set Change packets between provider and consumer chain. You should be proficient in setting up and running either [Hermes](https://github.com/informalsystems/hermes) or [rly](https://github.com/cosmos/relayer).
|
||||
|
||||
By the end of this phase, you are able to launch a consumer chain within a local testnet or CI workflow that resembles the testnet (or mainnet) environment.
|
||||
|
||||
### Planning with Testnet Coordinators
|
||||
|
||||
Once you have a binary release ready, you can begin planning the launch with the testnet coordinators (Hypha).
|
||||
|
||||
The goals of this phase are to update this repository with all the information validators need to join the network and to produce a `consumer-addition` proposal to be submitted in the provider chain.
|
||||
|
||||
We expect you to run the minimum infrastructure required to make your consumer chain usable by testnet participants. This means running:
|
||||
|
||||
1. **Seed/persistent nodes**
|
||||
2. **Relayer** it must be launched before the chain times out, preferably right after blocks start being produced.
|
||||
- **IMPORTANT**: Make sure you have funds to pay gas fees for the relayer. You will likely need to set up an adequately funded genesis account for this purpose.
|
||||
|
||||
Additionally, you may want to run:
|
||||
|
||||
- a faucet such as this simple [REST faucet](https://github.com/hyphacoop/cosmos-rest-faucet) (it may need a separate funded account in the genesis file as well)
|
||||
- a block explorer such as [ping.pub](https://github.com/ping-pub/explorer)
|
||||
|
||||
## ✍️ Submitting a PR for a new chain
|
||||
|
||||
Each consumer chain gets its own directory. You can use the [`slasher`](./stopped/slasher/) chain as reference. Feel free to clone the slasher directory, modify it for your consumer chain, and make a PR with the relevant information.
|
||||
|
||||
Hypha will be reviewing the PR to ensure it meets the following criteria:
|
||||
|
||||
#### README includes:
|
||||
|
||||
- [ ] Consumer chain repo and release or tag name.
|
||||
- [ ] Build instructions for chain binary.
|
||||
- [ ] Checksum of genesis file without CCV.
|
||||
- [ ] Checksum of reference binary.
|
||||
- [ ] Instructions on to join
|
||||
- [ ] Installation steps
|
||||
- Endpoints
|
||||
- [ ] Seeds OR persistent peers
|
||||
- [ ] State sync nodes (if any)
|
||||
|
||||
See the `slasher` chain [page](./stopped/slasher) for reference.
|
||||
|
||||
#### `chain_id` must be identical in the following places:
|
||||
|
||||
- [ ] `README`
|
||||
- [ ] genesis file
|
||||
- [ ] consumer addition proposal
|
||||
- [ ] bash script
|
||||
|
||||
We recommend choosing a `chain_id` with the suffix `-1`, even if it's a subsequent test of the same chain, e.g. `testchain-second-rehearsal-1`.
|
||||
|
||||
#### Binary checksum validation
|
||||
|
||||
- [ ] `shasum -a 256 <binary>` matches the checksum in the proposal
|
||||
- [ ] `shasum -a 256 <binary>` matches `README`
|
||||
|
||||
#### Bash script
|
||||
|
||||
- [ ] version built in script must match `README`
|
||||
- [ ] seeds or persistent peers must match `README`
|
||||
|
||||
#### Genesis file
|
||||
|
||||
- [ ] Genesis time must match spawn time in the `consumer-addition` proposal
|
||||
- [ ] Accounts and balances: Properly funded accounts (e.g., gas fees for relayer, faucet, etc.)
|
||||
- [ ] Bank balance denom matches denom in `README`
|
||||
- [ ] Slashing parameters: Set `signed_blocks_window` and `min_signed_per_window` adequately to ensure validators have at least 12 hours to join the chain after launch without getting jailed
|
||||
- [ ] `shasum -a 256 <genesis file without CCV>` matches the checksum in the proposal
|
||||
- [ ] `shasum -a 256 <genesis file without CCV>` matches the checksum in the `README`
|
||||
- [ ] The genesis file is correctly formed: `<consumer binary or gaiad> validate-genesis /path/to/genesis-without-ccv.json` returns without error
|
||||
|
||||
See the `slasher` chain [genesis](./stopped/slasher/slasher-genesis-without-ccv.json) for reference.
|
||||
|
||||
#### `consumer-addition` proposal
|
||||
|
||||
- [ ] Spawn time must match genesis time
|
||||
- [ ] Spawn time must be later than voting period
|
||||
- [ ] `revision_height: 1`
|
||||
- [ ] `revision_number: 1` (only if the `chain_id` ends in `-1`)
|
||||
- [ ] `transfer_timeout_period: 1800000000000`. This value should be smaller than `blocks_per_distribution_transmission * block_time`.
|
||||
- [ ] `ccv_timeout_period: 2419200000000000`. This value must be larger than the unbonding period, the default is 28 days.
|
||||
- [ ] `unbonding_period: 1728000000000000` (given current provider params)
|
||||
|
||||
See the `slasher` chain consumer-addition [proposal](./stopped/slasher/proposal-slasher.json) and [Interchain Security time-based parameters](https://github.com/cosmos/interchain-security/blob/main/docs/params.md#time-based-parameters) for reference.
|
||||
|
||||
#### Node configurations
|
||||
|
||||
- [ ] `minimum_gas_prices`
|
||||
- [ ] Check with Hypha about any other chain-specific params
|
||||
|
||||
---
|
||||
|
||||
### On-chain Proposal Submission
|
||||
|
||||
When you make your proposal, please let us know well in advance. The current voting period is five minutes, which means we’ll need to vote right after you submit your proposal. We recommend submitting the proposal together with us on a call.
|
||||
|
||||
The following will take place during the proposal submission phase:
|
||||
|
||||
- Your team will submit the `consumer-addition` proposal with a command that looks like this:
|
||||
```
|
||||
gaiad tx gov submit-legacy-proposal consumer-addition proposal.json --from <account name> --chain-id provider --gas auto --fees 500uatom -b block -y
|
||||
```
|
||||
- Testnet coordinators will vote on it shortly afterwards to make sure it passes.
|
||||
- You will open a pull request to add the new consumer chain entry to this repo and update the [schedule page](SCHEDULE.md) with the launch date.
|
||||
- You will announce the upcoming launch, including the spawn time, in the Interchain Security `announcements` channel of the Cosmos Network Discord Server. If you need permissions for posting, please reach out to us.
|
||||
|
||||
### Chain Launch
|
||||
|
||||
After the spawn time is reached, the Cross-Chain Validation (CCV) state will be available on the provider chain and the new IBC client will be created. At this point, you will be able to:
|
||||
|
||||
- Collect the Cross-Chain Validation (CCV) state from the provider chain.
|
||||
```
|
||||
gaiad q provider consumer-genesis <chain-id> -o json > ccv-state.json
|
||||
```
|
||||
- Update the genesis file with the CCV state.
|
||||
```
|
||||
jq -s '.[0].app_state.ccvconsumer = .[1] | .[0]' <consumer genesis without CCV state> ccv-state.json > <consumer genesis file with CCV state>
|
||||
```
|
||||
- Publish the genesis file with CCV state to the testnets repo.
|
||||
- Post the link to the genesis file and the SHA256 hash to the Interchain Security `interchain-security-testnet` channel of the Cosmos Network Discord Server.
|
||||
- Ensure the required peers are online for people to connect to.
|
||||
|
||||
The consumer chain will start producing blocks as soon as 66.67% of the provider chain's voting power comes online. You will be able to start the relayer afterwards:
|
||||
|
||||
- Query the IBC client ID of the provider chain.
|
||||
```
|
||||
gaiad q provider list-consumer-chains
|
||||
```
|
||||
- Create the required IBC connections and channels for the CCV channel to be established. Using Hermes:
|
||||
```
|
||||
hermes create connection --a-chain <consumer chain ID> --a-client 07-tendermint-0 --b-client <provider chain client ID>
|
||||
hermes create channel --a-chain <consumer chain ID> --a-port consumer --b-port provider --order ordered --a-connection connection-0 --channel-version 1
|
||||
```
|
||||
- Start the relayer
|
||||
- The trusting period fraction is set to `0.25` on the provider chain, so you should use a trusting period of 5 days in your relayer configuration.
|
||||
|
||||
Finally, the testnet coordinators will:
|
||||
|
||||
- Trigger a validator set update in the provider chain to establish the CCV channel and verify the validator set has been updated in the consumer chain.
|
||||
- Announce the chain is interchain secured.
|
||||
- Update the testnets repo with the IBC information.
|
||||
|
||||
## Talk to us
|
||||
|
||||
If you're a consumer chain looking to launch, please get in touch with Hypha. You can reach Lexa Michaelides at `lexa@hypha.coop` or on Telegram.
|
||||
@@ -0,0 +1,104 @@
|
||||
## `x/did` - Auth & AuthZ
|
||||
|
||||
> The DID module is responsible for managing the creation and management of DIDs.
|
||||
> Controllers represent on-chain accounts backed by a MPC keypair. Controllers
|
||||
> provide methods for Wallet Account Abstraction (WAA) and are responsible for
|
||||
> managing the creation and management of DIDs for an individual user.
|
||||
|
||||
### Features
|
||||
|
||||
- DID Controllers leverage the Cosmos SDK's `x/accounts` std interface for WAA.
|
||||
- DIDs are represented by a `x/did` controller and are required to state the
|
||||
controller's public key, and which map to the controller's capabilities.
|
||||
- General Sign/Verify methods are provides from the QueryServer for HTTP requests.
|
||||
- The Execute method is used to broadcast transactions across the network. (TODO)
|
||||
- Biscuits are used to authenticate and authorize requests between services. (TODO)
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/did#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/did#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/did#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/did#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/did#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/did#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/did#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/did#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/did#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/macaroon`
|
||||
|
||||
> The macaroon module is responsible for issuing and verifying macaroons. Macaroons
|
||||
> are used to authenticate and authorize requests between services.
|
||||
> Macaroons are requested by NFT Records from [`x/service`](2-‐-Modules-Overview.md#x-service) and granted by controllers from [`x/did`](2-‐-Modules-Overview.md#x/did)
|
||||
|
||||
### Features
|
||||
|
||||
- On Controller creation, a macaroon is created with an admin scope and a default expiry of _315,569,520 blocks (or ~10 years)_.
|
||||
- On Service registration, a macaroon is created with a service scope and a default expiry of _31,556,952 blocks (or ~1 year)_.
|
||||
- Macaroons contain the scope of access for a service and the expiry of the permissions in `blockHeight`.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/macaroon#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/macaroon#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/macaroon#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/macaroon#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/macaroon#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/macaroon#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/macaroon#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/macaroon#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/service`
|
||||
|
||||
> The service module is responsible for managing decentralized services. Services
|
||||
> on the Sonr network are essentially on-chain MultiSig wallets that are
|
||||
> represented by a NFT. Service admins are represented by
|
||||
> a [`x/did`](2-‐-Modules-Overview.md#x-did) controller and are required to state
|
||||
> the service's scope of access, and which map to the services' capabilities.
|
||||
|
||||
### Features
|
||||
|
||||
- Needs a Valid Domain with .htaccess file to be whitelisted.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/service#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/service#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/service#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/service#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/service#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/service#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/service#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/service#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/service#appendix)
|
||||
|
||||
---
|
||||
|
||||
## `x/vault`
|
||||
|
||||
> The vault module is responsible for managing the storage and acccess-control of
|
||||
> Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and
|
||||
> are represented by a [`x/did`](2-‐-Modules-Overview.md#x-did) controller.
|
||||
|
||||
### Features
|
||||
|
||||
- Vaults can be created by anyone, but efforts are made to restrict 1 per user.
|
||||
- Vaults are stored in IPFS and when claimed, the bech32 Sonr Address is pinned to IPFS.
|
||||
|
||||
### References
|
||||
|
||||
- [State](https://github.com/onsonr/sonr/tree/develop/x/vault#state)
|
||||
- [State Transitions](https://github.com/onsonr/sonr/tree/develop/x/vault#state-transitions)
|
||||
- [Messages](https://github.com/onsonr/sonr/tree/develop/x/vault#messages)
|
||||
- [Queries](https://github.com/onsonr/sonr/tree/develop/x/vault#query)
|
||||
- [Params](https://github.com/onsonr/sonr/tree/develop/x/vault#params)
|
||||
- [Client](https://github.com/onsonr/sonr/tree/develop/x/vault#client)
|
||||
- [Future Improvements](https://github.com/onsonr/sonr/tree/develop/x/vault#future-improvements)
|
||||
- [Tests](https://github.com/onsonr/sonr/tree/develop/x/vault#tests)
|
||||
- [Appendix](https://github.com/onsonr/sonr/tree/develop/x/vault#appendix)
|
||||
@@ -0,0 +1,11 @@
|
||||
> In order to maintain a tight-knit experience, we designed Sonr to operate completely
|
||||
> in the point-of-view of the user. This led to us building a Component Library which
|
||||
> creates consistent UX across the entire ecosystem.
|
||||
|
||||
# Overview
|
||||
|
||||
The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
|
||||
|
||||
# Nebula Package
|
||||
|
||||
> The total supply of `$SNR` is fixed at 1 billion.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Interchain Accounts
|
||||
|
||||
:::note Synopsis
|
||||
Learn about what the Interchain Accounts module is
|
||||
:::
|
||||
|
||||
## What is the Interchain Accounts module?
|
||||
|
||||
Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC.
|
||||
|
||||
- How does an interchain account differ from a regular account?
|
||||
|
||||
Regular accounts use a private key to sign transactions. Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.
|
||||
|
||||
## Concepts
|
||||
|
||||
`Host Chain`: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. Cosmos SDK messages) for which the interchain account will execute.
|
||||
|
||||
`Controller Chain`: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.
|
||||
|
||||
`Interchain Account`: An account on a host chain created using the ICS-27 protocol. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain will send IBC packets to the host chain which signals what transactions the interchain account should execute.
|
||||
|
||||
`Authentication Module`: A custom application module on the controller chain that uses the Interchain Accounts module to build custom logic for the creation & management of interchain accounts. It can be either an IBC application module using the [legacy API](10-legacy/03-keeper-api.md), or a regular Cosmos SDK application module sending messages to the controller submodule's `MsgServer` (this is the recommended approach from ibc-go v6 if access to packet callbacks is not needed). Please note that the legacy API will eventually be removed and IBC applications will not be able to use them in later releases.
|
||||
|
||||
## SDK security model
|
||||
|
||||
SDK modules on a chain are assumed to be trustworthy. For example, there are no checks to prevent an untrustworthy module from accessing the bank keeper.
|
||||
|
||||
The implementation of ICS-27 in ibc-go uses this assumption in its security considerations.
|
||||
|
||||
The implementation assumes other IBC application modules will not bind to ports within the ICS-27 namespace.
|
||||
|
||||
## Channel Closure
|
||||
|
||||
The provided interchain account host and controller implementations do not support `ChanCloseInit`. However, they do support `ChanCloseConfirm`.
|
||||
This means that the host and controller modules cannot close channels, but they will confirm channel closures initiated by other implementations of ICS-27.
|
||||
|
||||
In the event of a channel closing (due to a packet timeout in an ordered channel, for example), the interchain account associated with that channel can become accessible again if a new channel is created with a (JSON-formatted) version string that encodes the exact same `Metadata` information of the previous channel. The channel can be reopened using either [`MsgRegisterInterchainAccount`](./05-messages.md#msgregisterinterchainaccount) or `MsgChannelOpenInit`. If `MsgRegisterInterchainAccount` is used, then it is possible to leave the `version` field of the message empty, since it will be filled in by the controller submodule. If `MsgChannelOpenInit` is used, then the `version` field must be provided with the correct JSON-encoded `Metadata` string. See section [Understanding Active Channels](./09-active-channels.md#understanding-active-channels) for more information.
|
||||
|
||||
When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed. In order to change the ordering of the channel, the channel has to go through a [channel upgrade handshake](../../01-ibc/06-channel-upgrades.md) or reopen the channel with a custom controller implementation.
|
||||
@@ -0,0 +1,10 @@
|
||||
> With increasingly sensitive information being stored in centralized databases, we
|
||||
> believe that a decentralized anonymity mechanism is the only way to protect user data.
|
||||
> Sonr is at its core a peer-to-peer identity system, which means that users can choose
|
||||
> to share their identity with others in a way that is private and secure.
|
||||
|
||||
# Decentralized Identifiers
|
||||
|
||||
# Cross-chain Interoperability
|
||||
|
||||
# W3C Web APIs
|
||||
@@ -0,0 +1,11 @@
|
||||
> The `$SNR` token is the native platform token of the Sonr network. It is used by services to
|
||||
> pay for Authentication and Authorization services. The system is designed for developers to
|
||||
> be similar to centralized authentication providers like Google, Facebook, Okta, etc.
|
||||
|
||||
# Usage
|
||||
|
||||
The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
|
||||
|
||||
# Supply
|
||||
|
||||
> The total supply of `$SNR` is fixed at 1 billion.
|
||||
@@ -0,0 +1,21 @@
|
||||
> Sonr is a decentralized platform that allows users to create and manage their own decentralized identity.
|
||||
|
||||
# Blockchain: Sonr
|
||||
|
||||
Sonr stores Decentralized Identifiers (DIDs) on its Cosmos-sdk based blockchain. The blockchain's role is to act as the
|
||||
persistent pointer store for locations of User owned data.
|
||||
|
||||
# User Key Vault: Motr
|
||||
|
||||
The Motr node is a service-worker which functions as a personal encrypted key-enclave for users stored on IPFS. They can be allocated and persisted on the
|
||||
Sonr blockchain for Smart Wallet functionality.
|
||||
|
||||
# Network Gateway: Hway
|
||||
|
||||
The Hway protocol is a network proxy which routes network requests to the appropriate service endpoint. This is used for seamless communication between
|
||||
Blockchain Nodes, Decentralized Applications, and User Nodes.
|
||||
|
||||
# Design System: Nebula
|
||||
|
||||
Built with Golang-Templ, TailwindCSS, HTMX, and Service Workers - Nebula is a component library which allows for
|
||||
consistent UX across the entire ecosystem.
|
||||
@@ -0,0 +1,13 @@
|
||||
> The `$SNR` token is the native platform token of the Sonr network. It is used by services to
|
||||
> pay for Authentication and Authorization services. The system is designed for developers to
|
||||
> be similar to centralized authentication providers like Google, Facebook, Okta, etc.
|
||||
|
||||
# Usage
|
||||
|
||||
The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.
|
||||
|
||||
# Supply
|
||||
|
||||
> The total supply of `$SNR` is fixed at 1 billion.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user