pink: mq egress & discover ink instantiated contracts #538
Conversation
kvinwang
force-pushed
the
update-rustc
branch
from
63acfcd to
2db1b2d
Compare
Connect the chain block number and timestamp to pink contract.
kvinwang
changed the title
kvinwang
changed the title
| @@ -66,7 +72,16 @@ mod support { | |||
| req: OpaqueQuery, | |||
| context: &mut QueryContext, | |||
| ) -> Result<OpaqueReply, OpaqueError>; | |||
| fn process_messages(&mut self, env: &mut ExecuteEnv); | |||
| fn group_id(&self) -> Option<phala_mq::ContractGroupId>; | |||
There was a problem hiding this comment.
When does groupd_id return None?
There was a problem hiding this comment.
native contracts return None
| @@ -75,13 +90,16 @@ mod support { | |||
| type QResp: Encode + Debug; | |||
|
|
|||
| fn id(&self) -> ContractId; | |||
| fn group_id(&self) -> Option<phala_mq::ContractGroupId> { | |||
| None | |||
There was a problem hiding this comment.
Is it possible to assign the native contract to a special group id to simplify the logic elsewhere?
There was a problem hiding this comment.
Sounds good. But if we treat the native contract the same as pink, I think there will be more tricky things to be handle, such as state handling. It will be more error-prone.
| } | ||
|
|
||
| pub struct Group { | ||
| storage: pink::Storage, |
There was a problem hiding this comment.
Do the contracts within a group has the ability to access the storage from each other? We don't want it
There was a problem hiding this comment.
You mean inside the ink? It obey the original ink rules. The contract pallet maps the storage operations into a sub-trie in the group Storage.
There was a problem hiding this comment.
Sounds like fine, unless ink itself got some bug allowing sandbox bypassing. Let's keep an eye on it. We shouldn't allow contract direct storage access in anyway
No description provided.