add controller.getBundle(bundleID) -> bundle API

[warner]

What is the Problem Being Solved?

@michaelfig and @kriskowal are building the chain-side tools to install and retrieve source bundles. We have controller.validateAndInstallBundle() for the installation side, but we haven't yet written support for the retrieval side.

Description of the Design

controller.getBundle(bundleID) , which will return (synchronous) either an EndoZipBase64Bundle -shaped object (with keys moduleFormat, endoZipBase64, and endoZipBase64Sha512), or undefined.

Assuming nobody has bypassed the controller and used the (non-validating) kernel.installBundle(), the bundles returned by controller.getBundle will have been validated already.

getBundle() will query the database as seen by the kernel, which means it will see the contents of the crank buffer. If a bundle has been installed recently but the crank buffer has not been flushed to disk, getBundle() may return a bundle that is not yet nailed down on disk, and which might get discarded by a subsequent abortCrank() call. Therefore getBundle() should not be called while controller.run() / controller.step() is running (i.e. their return Promise has not yet fired).

It is safe to do c.validateAndInstallBundle() ; c.getBundle() on the same ID: the installation call will commit the crank before returning.

Security Considerations

Clients of a chain will use an RPC query that calls this function to obtain the source code being used on contracts. It must provide the same source code, with the same level of validation that the kernel itself uses.

Test Plan

unit tests in test/bundles/test-bundles-controller.js immediately after a c.validateAndInstallBundle() call

[Tartuffo]

@kriskowal Brian thought that you are working in this area as part of your bundle hash install. Can you do this while you are in there?

[kriskowal]

@warner I would like to prioritize this as “would be nice” in the MN-1 timeframe, but reading ahead, could be convinced that’s wishful thinking…

The interim solution is to recommend that people attempt to reconstruct the hash from sources for validation purposes. Yet, that interim solution would be greatly improved if we also allowed a bundle to be published with some metadata about how to reconstruct it, like the repository location and hash at the time of build. (Just rubber ducking this, I can see why much trouble is saved by instead providing a mechanism to download what was published to the chain from an RPC node, including that these notes could just be captured in the artifact proper. In #5541 I may have learned how to build some part of the solution you’re looking for here.)