[doc] README updates (#637)
This commit is contained in:
Jayant Krishnamurthy
GitHub
parent
b9430aee81
commit
c0b801ef15
|
|
@ -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!
|
||||
56
README.md
56
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
|
||||
|
||||
> 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.
|
||||
|
||||
[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.
|
||||
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
|
||||
|
||||
[pyth-js]: https://github.com/pyth-network/pyth-js
|
||||
|
||||
---
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
Loading…
Reference in New Issue