7d49366373
* Update `build-dependencies` CI action
* Update `develop` to `patch-polkadot-sdk`
Allows us to finally remove the old `serai-dex/substrate` repository _and_
should have CI pass without issue on `develop` again.
The changes made here should be trivial and maintain all prior
behavior/functionality. The most notable are to `chain_spec.rs`, in order to
still use a SCALE-encoded `GenesisConfig` (avoiding `serde_json`).
* CI fixes
* Add `/usr/local/opt/llvm/lib` to paths on macOS hosts
* Attempt to use `LD_LIBRARY_PATH` in macOS GitHub CI
* Use `libp2p 0.56` in `serai-node`
* Correct Windows build dependencies
* Correct `llvm/lib` path on macOS
* Correct how macOS 13 and 14 have different homebrew paths
* Use `sw_vers` instead of `uname` on macOS
Yields the macOS version instead of the kernel's version.
* Replace hard-coded path with the intended env variable to fix macOS 13
* Add `libclang-dev` as dependency to the Debian Dockerfile
* Set the `CODE` storage slot
* Update to a version of substrate without `wasmtimer`
Turns out `wasmtimer` is WASM only. This should restore the node's functioning
on non-WASM environments.
* Restore `clang` as a dependency due to the Debian Dockerfile as we require a C++ compiler
* Move from Debian bookworm to trixie
* Restore `chain_getBlockBin` to the RPC
* Always generate a new key for the P2P network
* Mention every account on-chain before they publish a transaction
`CheckNonce` required accounts have a provider in order to even have their
nonce considered. This shims that by claiming every account has a provider at
the start of a block, if it signs a transaction.
The actual execution could presumably diverge between block building (which
sets the provider before each transaction) and execution (which sets the
providers at the start of the block). It doesn't diverge in our current
configuration and it won't be propagated to `next` (which doesn't use
`CheckNonce`).
Also uses explicit indexes for the `serai_abi::{Call, Event}` `enum`s.
* Adopt `patch-polkadot-sdk` with fixed peering
* Manually insert the authority discovery key into the keystore
I did try pulling in `pallet-authority-discovery` for this, updating
`SessionKeys`, but that was insufficient for whatever reason.
* Update to latest `substrate-wasm-builder`
* Fix timeline for incrementing providers
e1671dd71b incremented the providers for every
single transaction's sender before execution, noting the solution was fragile
but it worked for us at this time. It did not work for us at this time.
The new solution replaces `inc_providers` with direct access to the `Account`
`StorageMap` to increment the providers, achieving the desired goal, _without_
emitting an event (which is ordered, and the disparate order between building
and execution was causing mismatches of the state root).
This solution is also fragile and may also be insufficient. None of this code
exists anymore on `next` however. It just has to work sufficiently for now.
* clippy
Serai
Serai is a new DEX, built from the ground up, initially planning on listing Bitcoin, Ethereum, DAI, and Monero, offering a liquidity-pool-based trading experience. Funds are stored in an economically secured threshold-multisig wallet.
Layout
-
audits: Audits for various parts of Serai. -
spec: The specification of the Serai protocol, both internally and as networked. -
docs: User-facing documentation on the Serai protocol. -
common: Crates containing utilities common to a variety of areas under Serai, none neatly fitting under another category. -
crypto: A series of composable cryptographic libraries built around theff/groupAPIs, achieving a variety of tasks. These range from generic infrastructure, to our IETF-compliant FROST implementation, to a DLEq proof as needed for Bitcoin-Monero atomic swaps. -
networks: Various libraries intended for usage in Serai yet also by the wider community. This means they will always support the functionality Serai needs, yet won't disadvantage other use cases when possible. -
message-queue: An ordered message server so services can talk to each other, even when the other is offline. -
processor: A generic chain processor to process data for Serai and process events from Serai, executing transactions as expected and needed. -
coordinator: A service to manage processors and communicate over a P2P network with other validators. -
substrate: Substrate crates used to instantiate the Serai network. -
orchestration: Dockerfiles and scripts to deploy a Serai node/test environment. -
tests: Tests for various crates. Generally,crate/src/testsis used, orcrate/tests, yet any tests requiring crates' binaries are placed here.
Security
Serai hosts a bug bounty program via Immunefi. For in-scope critical vulnerabilities, we will reward whitehats with up to $30,000.
Anything not in-scope should still be submitted through Immunefi, with rewards issued at the discretion of the Immunefi program managers.