Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new “Creating Verifiable Contracts” getting-started lesson that introduces SEP-58 and walks readers through producing reproducible Soroban contract builds with embedded verification metadata.
Changes:
- Introduces a new tutorial explaining verifiable contracts and SEP-58 metadata fields.
- Documents a container-pinned build flow that embeds
bldimg,bldopt,source_uri, andsource_sha256into the contract Wasm. - Provides a verification walkthrough showing how third parties reproduce and compare builds.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Thanks for this — the SEP-58 walkthrough reads great, and I see all the review feedback (env export, PowerShell env var, |
|
@leighmcculloch could you please review this new article on SEP-58? @ElliotFriend I'll get back to it asap. I need to follow it through from start to end and see if everything is working as described. |
|
It seems the PR preview isn't working. |
leighmcculloch
left a comment
leighmcculloch
left a comment
There was a problem hiding this comment.
Looks good, but definitely reads like it's been written with AI with a decent amount of filler. I suggested some rewords for the first couple paragraphs that do two things:
- Shift the speaking style so it isn't repeating "you" a lot, we don't need to refer to the reader because the article is not about the reader.
- Remove the filler, which in the two examples shifts from talking about what's being said, just saying what's the content.
And suggest doing a pass over the rest to do similar.
Everything otherwise looks right though so approving.
| import TabItem from "@theme/TabItem"; | ||
| import { getPlatform } from "@site/src/helpers/getPlatform"; | ||
|
|
||
| When you deploy a contract, only its compiled Wasm bytecode lives on-chain. Anyone can read that bytecode, but it tells them nothing about _which source code_ produced it. A **verifiable contract** closes that gap: it embeds enough information for an independent third party to take the published source, rebuild it, and confirm that the result is byte-for-byte identical to what's deployed. |
There was a problem hiding this comment.
"closes that gap" sounds like AI filler.
Suggest rewording:
| When you deploy a contract, only its compiled Wasm bytecode lives on-chain. Anyone can read that bytecode, but it tells them nothing about _which source code_ produced it. A **verifiable contract** closes that gap: it embeds enough information for an independent third party to take the published source, rebuild it, and confirm that the result is byte-for-byte identical to what's deployed. | |
| When a contract is deployed, anyone can read that bytecode, but it tells them nothing about _the original source code_ that produced it. A **verifiable contract** embeds enough information for an independent third party to discover the published source, rebuild it, and confirm that the result is byte-for-byte identical to what's deployed. |
|
|
||
| When you deploy a contract, only its compiled Wasm bytecode lives on-chain. Anyone can read that bytecode, but it tells them nothing about _which source code_ produced it. A **verifiable contract** closes that gap: it embeds enough information for an independent third party to take the published source, rebuild it, and confirm that the result is byte-for-byte identical to what's deployed. | ||
|
|
||
| This is what [SEP-58](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0058.md) standardizes. It defines a shared vocabulary for the build environment information needed to **reproduce a contract's Wasm bytes from source**, so that independent tools can interoperate without prescribing a single workflow. |
There was a problem hiding this comment.
| This is what [SEP-58](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0058.md) standardizes. It defines a shared vocabulary for the build environment information needed to **reproduce a contract's Wasm bytes from source**, so that independent tools can interoperate without prescribing a single workflow. | |
| [SEP-58](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0058.md) standardizes the build information required to be able to reproduce a contract's Wasm bytes from source and a set of meta fields for when that data is embedded in a contract. |
| ```sh | ||
| export RUSTUP_TOOLCHAIN=$(docker run --rm --entrypoint rustup "$IMAGE" default | cut -d' ' -f1) | ||
| ``` | ||
|
|
||
| </TabItem> | ||
|
|
||
| <TabItem value="windows" label="Windows (PowerShell)"> | ||
|
|
||
| ```powershell | ||
| $env:RUSTUP_TOOLCHAIN = (docker run --rm --entrypoint rustup $IMAGE default).Split(" ")[0] |
There was a problem hiding this comment.
Does this happen inside the image automatically?
No description provided.