[#48] frostfsid: Update contract #40
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-contract#40
Loading…
Reference in a new issue
No description provided.
Delete branch "dkirillov/frostfs-contract:poc/frostfsid"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
close #48
16773086a1
to229ce056c3
@ -160,0 +710,4 @@
}
func namespaceKey(ns string) []byte {
return namespaceKeyFromHash(ripemd160Hash(ns))
I suppose we use hashes because we want to allow strings of arbitrary lengths?
Yes.
@ -26,1 +11,3 @@
| `o` + ownerID + publicKey | ByteArray | it flags owner's public key |
| Key | Value | Description |
|---------------------------------------------------------------------------------|--------------------------------|----------------------------------------------------|
| `o` + [ owner address ] | []byte{1} | contract owners that can invoke write methods |
What kind of "owners" can be here besides the committee?
In case of TO this can be CM or IAM. But we have not decided yet should it be someone besides the committee @alexvanin
We want to have external validators. They can validate email, phone number or any other claim user may have. It isn't committee work to validate and approve such things.
These validators can create multi-signed transaction and multiaddress can be added as owner. These owners managed by committee \ consensus.
In trusted networks, validator key addresses can be added as owner, for example IAM service instances.
@ -27,0 +13,4 @@
| `o` + [ owner address ] | []byte{1} | contract owners that can invoke write methods |
| `s` + [ subject address ] | Serialized Subject structure | subject into |
| `a` + [ pk address ] + [ subject address ] | []byte{1} | link extra public keys for subject |
| `n` + [ RIPEMD160 of namespace ] | Serialized Namespace structure | namespace info |
Is there any reason we use RIPEMD instead of SHA256 which is also supported by the VM?
specifically for this key there isn't any reason besides consistency and possibility reusing already computed ns hash for other keys (but currently as I see we don't do this)
@ -47,2 +73,2 @@
if len(args.addrNetmap) != interop.Hash160Len || len(args.addrContainer) != interop.Hash160Len {
panic("incorrect length of contract script hash")
for _, owner := range args.owners {
if len(owner) != interop.Hash160Len {
In some places
ownerID
is 25 bytes (+ 1-byte prefix + 4-byte checksum), in others just neo address.I like 20-bytes better, but could this cause problems?
I'm not sure. I think we can require use 20-bytes address. We also provide client to interact with contract that make client use the addresses that we expect
@ -160,0 +173,4 @@
panic("address not found")
}
subject := std.Deserialize(data).(Subject)
subject.AdditionalKeys = append(subject.AdditionalKeys, key)
This can cause conflict when multiple keys are added at the same time: array serialization is done with
varuint
Not sure my concern is practical, though.
We can add multiple keys in the same transaction (isn't this enough to cover use-cases?):
@ -0,0 +1,20 @@
package commonclient
What about using
neo-go contract generate-rpcwrapper
?It generates actor-friendly interface together with all wrappers, even event parsers.
#47
Hm... Looks good but as I understand we want more user-friendly client so we will have to add some wrappers for generated client. Thus I'm not sure if it worth to rewrite code right now. Probably we can update it a little bit later, after #47 be merged and when we open this PR for review
I'm not sure if it makes sense to use generated wrappers in
frostfsid/client
package. Because of:result.Invoke
in functions like this but generated wrapper doesn't provide such thing7b4207f779
to2af51ee8f4
WIP: [#XX] frostfsid: Update contractto [#XX] frostfsid: Update contract[#XX] frostfsid: Update contractto [#48] frostfsid: Update contract@ -160,0 +130,4 @@
addr := contract.CreateStandardAccount(key)
sKey := subjectKeyFromAddr(addr)
data := storage.Get(ctx, sKey).([]byte)
if data != nil {
Would not be better to check with
if len(data) > 0
?I know this barely may happen but
I believe this nil is actually
Null
, solen
check will panic (and it costs more anyway)Ah, okay! Thanks
@pogpp has some question for group related operations. I suggest to address them in this PR and then merge it.
/cc @dkirillov
frostfs-adm support PR TrueCloudLab/frostfs-node#793
c830abacad
to80fd9d593e
80fd9d593e
toe2e406932f
@ -57,0 +98,4 @@
storage.Delete(ctx, ownerKey(addr))
}
func ListOwners() iterator.Iterator {
As I understand, the list of owners is small, almost certainly less than 10.
In this case returning an array seems a better option, what do you think?
Will we have 100 owners in private 100-node installation?
Well, it depends -- multisig 1 of N is also an option.