39ce819876
* add slash tx * ignore unsigned tx replays * verify that provided evidence is valid * fix clippy + fmt * move application tx handling to another module * partially handle the tendermint txs * fix pr comments * support unsigned app txs * add slash target to the votes * enforce provided, unsigned, signed tx ordering within a block * bug fixes * add unit test for tendermint txs * bug fixes * update tests for tendermint txs * add tx ordering test * tidy up tx ordering test * cargo +nightly fmt * Misc fixes from rebasing * Finish resolving clippy * Remove sha3 from tendermint-machine * Resolve a DoS in SlashEvidence's read Also moves Evidence from Vec<Message> to (Message, Option<Message>). That should meet all requirements while being a bit safer. * Make lazy_static a dev-depend for tributary * Various small tweaks One use of sort was inefficient, sorting unsigned || signed when unsigned was already properly sorted. Given how the unsigned TXs were given a nonce of 0, an unstable sort may swap places with an unsigned TX and a signed TX with a nonce of 0 (leading to a faulty block). The extra protection added here sorts signed, then concats. * Fix Tributary tests I broke, start review on tendermint/tx.rs * Finish reviewing everything outside tests and empty_signature * Remove empty_signature empty_signature led to corrupted local state histories. Unfortunately, the API is only sane with a signature. We now use the actual signature, which risks creating a signature over a malicious message if we have ever have an invariant producing malicious messages. Prior, we only signed the message after the local machine confirmed it was okay per the local view of consensus. This is tolerated/preferred over a corrupt state history since production of such messages is already an invariant. TODOs are added to make handling of this theoretical invariant further robust. * Remove async_sequential for tokio::test There was no competition for resources forcing them to be run sequentially. * Modify block order test to be statistically significant without multiple runs * Clean tests --------- Co-authored-by: Luke Parker <lukeparker5132@gmail.com> |
||
|---|---|---|
| .github | ||
| audits/Cypher Stack crypto March 2023 | ||
| coins | ||
| common | ||
| coordinator | ||
| crypto | ||
| docs | ||
| message-queue | ||
| orchestration | ||
| processor | ||
| substrate | ||
| tests | ||
| .gitattributes | ||
| .gitignore | ||
| .rustfmt.toml | ||
| AGPL-3.0 | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| LICENSE | ||
| README.md | ||
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. -
docs: 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. -
coins: Various coin 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.