Remove redundant information from the readme (#468)

3 years ago · 5ab347e43a
parent 9e081a43f6
commit 5ab347e43a
1 changed files with 4 additions and 101 deletions
--- a/README.md
+++ b/README.md
@ -2,79 +2,14 @@
 ## Overview
-Abacus is an interchain messaging protocol. It handles passing generalized messages
+Abacus is an interchain messaging protocol that allows applications to communicate between blockchains.
 between blockchains cheaply, enabling genuine interchain applications. Inspired by IBC,
 Abacus creates channels between chains. In that respect, Abacus is a network between blockchains,
 and then passes messages between applications over these channels. Channels can be used 
 by numerous applications on any source or destination chain. Abacus is implemented wholly in
 smart contracts, and thus can be implemented in any turing complete smart contract chain.
-Unfortunately, while Abacus might feel like magic, it isn't actually magic. Something's got to give.
+Developers can use Abacus to share state between blockchains, allowing them to build interchain applications that live natively across multiple chains.
 When contrasted against IBC and other communication protocols based on PoS light clients, 
 Abacus does have weaker security guarantees. It trades off generalizability, economies of scale
 and ease of implementation against securuity guarantees. That said, Abacus augments 
 it's PoS security model with what we call Sovereign Consensus, which allows 
 any Abacus application to define arbitrary rules which are a pre-condition
 for messages being processed. You can read more about Sovereign Consensus [here](https://docs.useabacus.network/abacus-docs/protocol/security/sovereign-consensus)
-Other than its unique security model, Abacus is different from IBC and other 
+To read more about interchain applications, how the protocol works, and how to integrate with Abacus, please see the [documentation](https://docs.useabacus.network/).
 interchain communication protocols in a major way; Abacus may be implemented on any smart
 contract platform without a need for light client engineering. Since it does not run
 a light client, Abacus doesn't need to spend extra gas verifying block headers,
 a major efficiency gain for such a system. 
 Said succintly, Abacus was built to prioritize:
 - Simplicity: A simple interface for establishing and maintaining connection between applications.
 - Speed of implementation: Can be impelemented on any smart contract chain, PoS + SC security model for lower latency.
 - Cost: No header verification or state management. Economies of scale in messaging overhead.
 You can read more about Abacus' architecture in the [documentation](https://docs.useabacus.network/).
 ## Integrating with Abacus
 Abacus establishes communication channels with other chains, but it's up to app
 developers to use those. This repo provides a standard pattern for integrating
 Abacus channels, and ensuring that communication is safe and secure.
 Integrations require a few key components:
 - A `Outbox` and any number of `Inbox` contracts deployed on the chain already.
  These contracts manage Abacus communication channels and will be used by the
  app to send and receive messages.
 - An `AbacusConnectionManager` (in `solidity/core/contracts`). This
  contract connects the app to Abacus by allowing the app admin to enroll new
  `Outbox` and `Inbox` contracts. Enrolling and unenrolling channels is the
  primary way to ensure that your app handles messages correctly. Apps may
  deploy their own connection manager, or share one with other apps.
 - A `Message` library. Abacus sends raw byte arrays between chains. The app
  must define a message specification that can be serialized for sending, and
  deserialized for handling on the remote chain
 - A `Router` contract. The router translates between the Abacus cross-chain
  message format, and the local chain's call contract. It also implements the
  business logic of the app. It exposes the user-facing interface, handles
  messages coming in from other chains, and dispatches messages being sent to
  other chains.
 Solidity developers interested in implementing their own `Message` library and
 `Router` contract should check out the [apps](./solidity/apps/) package. It contains several example applications.
 You can find current testnet deploy configurations in the `rust/config/`
 directory. These deployments happen frequently and are unstable. Please feel
 free to try out integrations using the deployed contracts in the LATEST config.
 ## Working on Abacus
 ### Commit signature verification
 Commits (and tags) for this repo require [signature verification](https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/about-commit-signature-verification). If you'd like to contribute to Abacus, make sure that your commits are signed locally.
 ### Workspaces
 This monorepo uses [Yarn Workspaces](https://yarnpkg.com/features/workspaces). Installing dependencies, building, testing, and running prettier for all packages can be done from the root directory of the repository.
@ -105,6 +40,7 @@ If you are using [VSCode](https://code.visualstudio.com/), you can launch the [m
 - see `rust/README.md`
 ### Running Agents Locally
 See [this guide](rust/running-locally.md) for how to run the agents locally and perform a full end-to-end test.
 #### Building Agent Images
@ -117,39 +53,6 @@ cd rust
 ./release.sh <image_tag>
 ```
 ## Key Points
 System outline:
 1. An "outbox" contract on a source chain receives messages from applications and commits messages in a merkle tree
 2. Staking "validators" attest to the commitment via "checkpoints"
 3. Attested checkpoints are relayed to any number of "inbox" contract on any number of destination chains
 4. Messages are processed, not before they are checked against the Sovereign Consensus rules of destination applications.
 As a result, one of the following is always true:
 1. All inboxes have a valid commitment to messages from the outbox chain
 2. Misbehaving validators can be slashed on the outbox chain
 While this guarantee may be weaker than header verification in its own right, when augmented with Sovereign Consensus we believe it is more than sufficient for even the most high stakes applications.
 ## Summary
 Abacus is a protocol for interchain communication. The protocol's goal is to use generalized messaging between smart contract blockchains to enable interchain applications. 
 To enable this capability Abacus creates a succinct piece of state, a 32 byte hash, that is updated regularly. This enables the protocol to have economies of scale with respect to messaging frequency.
 This hash is effectively a merkle tree containing a set of interchain messages sent by a collection of applications on a source chain via an Outbox. The root of the merkle tree can be relayed to any number of destination chains via an Inbox. 
 The outbox chain designates validators. A validator places a bond as stake ensuring
 their good behavior. They are responsible for producing signed attestations of the
 new message tree root. These attestations are relayed to inboxes on destination chains.
 The inbox accepts a checkpoint attestation signed by validators. Because this root
 contains a commitment of all messages sent by the source chain outbox, these messages
 can be proven (using the inbox's root) and then dispatched to contracts on the
 destination chain inbox.
 ## Deploy Procedure
 The contract addresses of each deploy can be found in `rust/config`. The latest