I thought that the following pattern would be preferable in an async world.
fn update(x_transid: i64, key:i32, value:i32) → bool {
// x_transid is expcted to be unique. Only one call to x_transid will succeed in external call ; if at all…every other call will fail
// therefore reducers will ALWAYS return true
}
fn lookup(x_transid: i64, key: i32) → bool {
// did update suceed in external call with key being updated with attached x_transid
}
So you make the call to update; but rely on lookup to know whether the update actually suceeded. Of course support is required from the external system.
Well observed! Indeed, we are implementing a simple sample dApp in Rust and Motoko. The dApp will pull ICP exchange rates from Coinbase and offer the rates over an on-chain API.
What the feature will be capable of is to allow canisters to make GET requests to external services and receive the (transformed) response. If responses of the Web 2 server are not deterministic, you need to define a transform function to make it deterministic, i.e., remove non-deterministic attributes like timestamps and session ids. This allows then all replicas to receive the same transformed response and let consensus agree on it.
POST
Doing POST calls is a rather small extension that would be added after an initial release. Doing a post with this feature assumes that the Web 2 service can handle that the same request be made by all nodes of the subnet. Web 2 services that support the Idempotency-Key header as specified in the draft RFC should work for correctly processing POST requests when using the Idempotency-Key header in the request.
It’s definitely not implemented by every service. So this is something that practically limits the possibility of POST requests to Web 2.0 HTTP-based services using the current version of this feature.
We are currently wrapping up the MVP implementation of the feature, only a few small things remain to be done. We plan to launch the feature in July. The MVP will be an IPv6-only launch for the reason of our replicas not having IPv4 addresses. Going via boundary nodes, as initially planned, may be added at a later stage, but the main issue is that all subnets then share the rate limits of services as we only have 10-20 boundary nodes currently.
What is missing now are the following items:
Merge some MRs that are under review
Finish the sample dApp demonstrating the feature (ICP price quotes from Coinbase)
HEAD and POST extensions and corresponding system test
Local https-capable setup for system tests (currently going via external site); requires support for self-signed certificates
Enable SDK (almost done, still requires replica with feature to be shipped)
Cycles charging: decision on price (under discussion)
Using the opportunity of a short interruption of my hiking vacation to give you an update.
The feature is now code complete and waiting for its documentation to be finalized and some infrastructure configuration changes to be done before we can release it. Those infrastructure changes are required in order to prevent canisters from trying to access ports of internal services (e.g., logging) that are accessible from replicas (and thereby would be accessible also from canisters, and not just replicas, with this feature becoming available). For according security, to prevent this access already at the networking level and not rely solely on access control within the feature, this needs to be addressed. Thus, in the spirit of a defense-in-depth design principle, the feature is blocked on those infrastructure changes.
Security is a primary concern, hope you all understand this! We hope to be close to the most recent plan of launching the feature be end of July 2022. Maybe it slips a little into August, depending on the effort to make the infrastructure changes.
Maybe they take this (delayed things) just completely for granted as the time going, I really don’t like to complain but dfinity team really bad at estimation. Really hope the team could do better next times… @dieter.sommer seems that nobody from outside could trust a team that break the plans again and again, so maybe that’s one of the reasons the price is down so heavy…
(I am going to get on my soapbox a bit and defend Dieter and some of my fellow colleagues working hard on this feature)
Let’s give the folks working on this project some slack here…
To be fair, enabling HTTP requests from smart contracts (in a secure way) is a feature that has eluded every blockchain. This team has taken a few months to do what no other chain has in years.
Did they underestimate the work necessary? Yes, but this is not surprising since they are literally inventing things so they are not sure what they will find as they build it (not to mention a litany of security reviews to make sure it is bulletproof).
I second this opinion from @diegop …copying the gist of something that i picked up from elsewhere in a completely different context(btc integration context)…
"…They are being super cautious; even if the math adds up. That is to say we know we can go to mars; but we really dont need an disaster to land on mars.
… This is …literally…a mission to mars project. It hasnt beem done before. Paving the road and learning along the way.
We have one shot and we better not screw it up. On the positive side, the worlds best team to handle these crypographic needs…"
We still need to conclude the following tasks before a release on the IC:
Making the infrastructure changes mentioned further above. Parts of it has been implemented already, parts are still to be done.
Reviewing and merging the code related to a major performance improvement resulting from the change of the signature scheme used to sign artifacts in the consensus layer. We wanted to get this out before a first release.
Writing and publishing the documentation for the feature.
The abovementioned performance improvement results in a major reduction of CPU overhead due to using a different signature scheme.
