diff --git a/aptos/docs/src/components/client.md b/aptos/docs/src/components/client.md index 133e5831..9d6b5c6a 100644 --- a/aptos/docs/src/components/client.md +++ b/aptos/docs/src/components/client.md @@ -21,4 +21,4 @@ the proofs generation in parallel. This flow happens during initialization where Aptos network while producing an inclusion proof for a given account at the latest block. The bundled example client currently only requests and verifies STARK proofs. The proof servers have support for generating -and verifying SNARK proofs, but the example client does not yet make use of this. +and verifying SNARK proofs, but the example client does not yet make use of this. \ No newline at end of file diff --git a/aptos/docs/src/design/overview.md b/aptos/docs/src/design/overview.md index 84ac78f1..52ca1826 100644 --- a/aptos/docs/src/design/overview.md +++ b/aptos/docs/src/design/overview.md @@ -26,7 +26,7 @@ to some account needs to be validated. The current Verifying Key Hashes which uniquely identify the specific RISC-V binaries for the proof programs, located in the [`aptos/aptos-programs/artifacts/`](https://github.com/lurk-lab/zk-light-clients/tree/dev/aptos/aptos-programs/artifacts) directory are: -* `epoch_change`: `0x00eea0650222f7e5bb6a2fe57c0e0e504d1df8b3d848d5116174a8703d228c94` +* `epoch_change`: `0x008f0133dc5a02eb31ac769e9e3a2f34da1af34c963bf3ee9a058982a2978cc9` * `inclusion`: `0x00336c570224c00161ca7b3c275c24f3968aa09086c31d09d98691bce109f4f6` -These values are also present in and used by the [solidity fixtures](../benchmark/on_chain.md). +These values are also present in and used by the [solidity fixtures](../benchmark/on_chain.md). \ No newline at end of file diff --git a/aptos/docs/src/misc/release.md b/aptos/docs/src/misc/release.md index 2b38f164..90e3b6bd 100644 --- a/aptos/docs/src/misc/release.md +++ b/aptos/docs/src/misc/release.md @@ -8,29 +8,29 @@ run it. The release process is mostly automated through the usage of GitHub Actions. A release should be initiated through the manually triggered GitHub Action **Bump Version**. When triggering a release, -the reference base that should be chosen is the `dev` branch, with a `release` type and the desired release version. The +the reference base that should be chosen is the `dev` branch, with a `release` type, `aptos` light-client and the desired release version. The specified release version should follow [the Semver standard](https://semver.org/). -This action opens a new PR from a branch named `release/` with `dev` as its base. A commit is +This action opens a new PR from a branch named `release/aptos-v` with `dev` as its base. A commit is automatically applied to bump all the `Cargo.toml` version of the relevant crates. The developer in charge of the release should use this branch to make any necessary updates to the codebase and documentation to have the release ready. Once all the changes are done, the PR can be squash and merged in `dev`. This will trigger the **Tag release** action -that is charged with the publication of a release and a tag named ``. +that is charged with the publication of a release and a tag named `v`. ## Hotfix process The hotfix process is quite similar to the release one. -**Bump Version** should also be triggered, but with the desired `release/` as reference. A PR will be -opened from a branch named `hotfix/` with the base `release/`. A commit is automatically +**Bump Version** should also be triggered, but with the desired `release/aptos-v` as reference. A PR will be +opened from a branch named `hotfix/aptos-v` with the base `release/aptos-v`. A commit is automatically applied to bump all the `Cargo.toml` version of the relevant crates. The developer in charge of the hotfix should use this branch to make any necessary updates to the codebase and documentation to have the hotfix ready. Once all the changes are done, the PR can be squash and merged in `release/`. This will trigger the -**Tag release** action that is charged with the publication of a release and a tag named ``. +**Tag release** action that is charged with the publication of a release and a tag named `v`. Finally, the developer will also need to port the changes made to `dev` so that they are reflected on the latest development stage of the Light Client.