[doc] README updates (#637)

CONTRIBUTING.md

@@ -1,68 +0,0 @@
-# Contributing
-
-Wormhole is an open-source project licensed under the permissive Apache 2 license. Contributions are greatly
-appreciated and will be reviewed swiftly.
-
-Wormhole is a mission-critical, high-stakes project. We optimize for quality over quantity. Design processes
-and code reviews are our most important tools to accomplish that.
-
-- All new features must first be discussed in a GitHub issue before starting to implement them. For
-  complex features, it can be useful to submit a [formal design document](design/template.md).
-
-- Development happens on a long-lived development branch (`dev.v2` and `dev.v1`).
-  Every change going into a development branch is reviewed individually (see below). Release branches may be used
-  to support in-the-wild releases of Wormhole. We aim to support at most two release
-  branches at the same time. Changes can be cherry-picked from the development branch to release branches, but
-  never from release branches to a development branch.
-
-- Releases are first tested on a testnet.
-
-- Commits should be small and have a meaningful commit message. One commit should, roughly, be "one idea" and
-  be as atomic as possible. A feature can consist of many such commits.
-
-- Feature flags and interface evolution are better than breaking changes and long-lived feature branches.
-
-- We optimize for reading, not for writing - over its lifetime, code is read much more often than written.
-  Small commits, meaningful commit messages and useful comments make it easier to review code and improve the
-  quality of code review as well as review turnaround times. It's much easier to spot mistakes in small,
-  well-defined changes.
-
-Documentation for the in-the-wild deployments lives in the
-[wormhole-networks](https://github.com/wormhole-foundation/wormhole-networks) repository.
-
-See [DEVELOP.md](./DEVELOP.md) for more information on how to run the development environment.
-
-## Contributions FAQ
-
-### Can you add \<random blockchain\>?
-
-The answer is... maybe? The following things are needed in order to fully support a chain in Wormhole:
-
-- The Wormhole mainnet is governed by a DAO. Wormhole's design is symmetric - every guardian node needs to run
-  a node or light client for every chain supported by Wormhole. This adds up, and the barrier to support new
-  chains is pretty high. Your proposal should clearly outline the value proposition of supporting the new chain.
-  **Convincing the DAO to run nodes for your chain is the first step in supporting a new chain.**
-
-- The chain needs to support smart contracts capable of verifying 19 individual secp256k1 signatures.
-
-- The smart contract needs to be built and audited. In some cases, existing contracts can be used, like with
-  EVM-compatible chains.
-
-- Support for observing the chain needs to be added to guardiand.
-
-- Web wallet integration needs to be built to actually interact with Wormhole.
-
-The hard parts are (1) convincing the DAO to run the nodes, and (2) convincing the core development team to
-either build the integration, or work with an external team to build it.
-
-Please do not open a GitHub issue about new networks - this repository is only a reference implementation for
-Wormhole, just like go-ethereum is a reference implementation for Ethereum. Instead, reach out to the
-[Wormhole Network](https://wormholenetwork.com).
-
-### Do you support \<random blockchain innovation\>?
-
-Probably :-). At its core, Wormhole is a generic attestation mechanism and is not tied to any particular kind
-of communication (like transfers). It is likely that you can use the existing Wormhole contracts to build your
-own features on top of, without requiring any changes in Wormhole itself.
-
-Please open a GitHub issue outlining your use case, and we can help you build it!

README.md

@@ -1,12 +1,7 @@
 # Pyth Crosschain
 
 This repository acts as a monorepo for the various components that make up
-Pyth Crosschain. The base repository is a fork from Certus One's reference
-[Wormhole][] implementation in order to take advantage of the existing tooling
-for building projects based on Wormhole's various SDKs. Much of the existing
-documentation from there will also apply to this repository.
-
-[wormhole]: https://github.com/wormhole-foundation/wormhole
+Pyth Crosschain.
 
 Within this monorepo you will find the following subprojects:
 
@@ -15,8 +10,8 @@ Within this monorepo you will find the following subprojects:
 > wormhole_attester
 
 The main Pyth implementation currently exists as an [on-chain contract][] on
-Solana. In order to expose these prices cross-chain, the Wormhole Attester
-contract acts as a sender for Pyth prices. At regular intervals the Pyth
+Pythnet, a separate instance of the Solana blockchain. In order to expose
+these prices cross-chain, the Wormhole Attester contract acts as a sender for Pyth prices. At regular intervals the Pyth
 contract will observe the current Pyth price for selected products, and produce
 an attestation which is then relayed over Wormhole to be consumed by the
 various receiver contracts.
@@ -25,45 +20,28 @@ various receiver contracts.
 
 ## Target Chains
 
-### Ethereum
-
-> target_chains/ethereum/contracts/pyth
-
-The Ethereum contract acts as a receiver for Pyth prices relayed from the
-Wormhole Attester. It also provides a public API for other Ethereum contracts
-that can be used to consume Pyth prices. For a guide on using this API to
-consume Pyth price feeds see [pyth-sdk-solidity][] which contains documented
-examples.
+> target_chains
 
-[pyth-sdk-solidity]: https://github.com/pyth-network/pyth-sdk-solidity
+This directory contains on-chain contracts and SDKs for all of the various
+blockchain runtimes that Pyth supports. Each subdirectory corresponds to a
+blockchain runtime. Inside each subdirectory, there are subfolders for
+contracts, SDKs, and examples.
 
 ## Price Service
 
 > price_service
 
 The Price Service is an off-chain service which constantly observes the
-Wormhole network watching for price attestations emitted from the Pyth Solana
+Wormhole network watching for price attestations emitted from the Pyth
 contract. It exposes all observed attestations via a public API over HTTPS/WSS
 which can be consumed by client-side applications that wish to use Pyth pricing
 data.
 
-For a guide on utilising this service in your project, see the documentation in
-the [pyth-js][] repository.
-
-[pyth-js]: https://github.com/pyth-network/pyth-js
-
----
+The `client` subdirectory provides an SDK for interacting with the price service.
+However, most users will interact with the price service via a chain-specific SDK
 
-See [DEVELOP.md](DEVELOP.md) for instructions on how to set up a local devnet, and
-[CONTRIBUTING.md](CONTRIBUTING.md) for instructions on how to contribute to this project.
-
-### Audit / Feature Status
-
-⚠ **This software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-implied. See the License for the specific language governing permissions and limitations under the License.** Or plainly
-spoken - this is a very complex piece of software which targets a bleeding-edge, experimental smart contract runtime.
-Mistakes happen, and no matter how hard you try and whether you pay someone to audit it, it may eat your tokens, set
-your printer on fire or startle your cat. Cryptocurrencies are a high-risk investment, no matter how fancy.
+For a guide on utilising this service in your project, see the chain-specific SDK
+and examples for your blockchain runtime in the `target_chains` directory.
 
 ## Development
 
@@ -80,3 +58,11 @@ The checks are also performed in the CI to ensure the code follows consistent fo
 ### Tilt CI
 
 Integration tests run in Tilt (via the `tilt ci` command). The Tilt CI workflow requires approval from a member of the Pyth team. If you are a member, click on "Details" next to the "Workflow / ci-pyth-crosschain" check in a pull request, and then on the "Resume" button on the workflow page.
+
+## Audit / Feature Status
+
+⚠ **This software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+implied. See the License for the specific language governing permissions and limitations under the License.** Or plainly
+spoken - this is a very complex piece of software which targets a bleeding-edge, experimental smart contract runtime.
+Mistakes happen, and no matter how hard you try and whether you pay someone to audit it, it may eat your tokens, set
+your printer on fire or startle your cat. Cryptocurrencies are a high-risk investment, no matter how fancy.

DEVELOP.md → tilt_devnet/README.md

@@ -1,6 +1,9 @@
-# Developing the bridge
+# Tilt Devnet
 
-## Local Devnet
+We use Tilt to run integration tests. These tests instantiate docker containers with all of the
+various blockchains and services in order to verify that they interoperate correctly.
+
+## Installation
 
 The following dependencies are required for local development:
 
@@ -8,14 +11,14 @@ The following dependencies are required for local development:
 - [Tilt](http://tilt.dev/) >= 0.20.8
 - Any of the local Kubernetes clusters supported by Tilt.
   We strongly recommend [minikube](https://kubernetes.io/docs/setup/learning-environment/minikube/) >=
-  v1.21.0 with the kvm2 driver.
+  v1.21.0 .
   - Tilt will use Minikube's embedded Docker server. If Minikube is not used, a local instance of
     [Docker](https://docs.docker.com/engine/install/) / moby-engine >= 19.03 is required.
 
 See the [Tilt docs](https://docs.tilt.dev/install.html) docs on how to set up your local cluster -
 it won't take more than a few minutes to set up! Example minikube invocation, adjust limits as needed:
 
-    minikube start --cpus=8 --memory=8G --disk-size=50G --driver=kvm2
+    minikube start --cpus=8 --memory=8G --disk-size=50G --driver=docker
 
 npm wants to set up an insane number of inotify watches in the web container which may exceed kernel limits.
 The minikube default is too low, adjust it like this: