Let’s say a canister needs to submit transactions to another chain whereby t-ECDSA does the signing and HTTPS outcalls reach out to a prepaid RPC endpoint. Putting the cycle costs of HTTPS outcalls and t-ECDSA aside, would this be a scalable architecture wrt t-ECDSA?
2 Likes
That sounds exactly like ETH integration phase 1. I don’t see anything wrong with this approach. Of course you have the single point of failure on the RPC endpoint, but you can also have multiple of those available
Thx for the quick response @Severin , given your input I’m going ahead with this. Two endpoints consuming my signed messages are supposedly high-availability, but yeah, good point, systems are only as strong as the weakest chain in the loop. I have a much bigger concern, based on my side: What happens if my canister traps, rendering all previously signed data unusable?
1 Like
How would a trap render all data unusable? Trapping only reverts to the state before the last entry point (function call or await)
Sorry my question wasn’t clear, let me break it down. For one of the two t-ECDSA signed message consuming endpoints in my architecture, a canister will be treated as a “service user” account owner on that endpoint, let’s call it M. I thought t-ECDSA’s derivation_path would be the canister_id, hence my assumption that a trapped canister situation would spawn a new canister_id making the previous canister_id linked derivation_path go in smokes, taking with it the “service user” of that endpoint.
1 Like
Sort-of, the the derivation path is canister id + the derivation_path you supply
There is no such thing as a ‘trapped canister’. You can make a canister stuck somehow, but you can always reinstall over it. If you lose access because you remove its controllers, yes, then it can get ‘lost’, but I think it’s pretty obvious if you do such dangerous operations and you’ll know to triple-check those situations
2 Likes
So reinstalling over a canister returns the same canister_id, therefore this redeployed canister code will be treated the same by t-ECDSA wrt derivation_path, correct? Surely the immutability goal is to black hole all canisters, I’ll pop a 
upon reaching that goal.
Correct. But I’d change the terminology a bit: install_code (the function actually called to modify the wasm, no matter if you use mode install/reinstall/upgrade/uninstall) is an operation that modifies a canister, so there is no reason for it to change addresses.
Are you maybe coming over from e.g. ETH? Over there smart contracts are immutable by default and if you want to change things you have to deploy a new contract. It’s not the same on the IC. You can modify and even delete your canister’s code in any way you want, and the underlying id stays the same
Such a useful design decision by Dfinity folks. Thx @Severin , t-ECDSA is clearer for me now.
1 Like