Implement service registry contract

[tahpot]

This task is for the smart contract implementation of Service Registry - Phase 1.

Smart contract requirements

The following smart contract requirements have been scoped based on the user stories in Phase 1.

Architecture overview

Methods:

registerService(did: string, serviceType: ServiceType, endpointUri: string, country: string, maxAccounts: integer, pricePerDayPerAccount: decimal, proof: string, consentBlock: integer)

Enable a Verida Infrastructure Operator to register a service.

proof is a signed message in the form:

${did} consents to registering a ${serviceType} at ${endpointUri}

Constraints:

• The Verida Infrastructure Operator must bond VDA tokens equal to (maxUsers * vdaPer<InfrastructureType>Account), where InfrastructureType can be determined by looking up serviceType from ServiceType lookup. These bonded tokens are removed from the account's credit and placed in a separate bonded tokens pool of VDA tokens within the smart contract. These bonded tokens will be paid to the Verida Infrastructure Operator every day via the distribute() function.
• Generates a unique serviceId that represents the service equal to hash(did+serviceType)
• proof must be signed by did and match the parameters supplied when calling the method. How to prevent replay attacks? Use block number range?

updateService(did: string, serviceId: string, maxAccounts: integer, pricePerAccount: decimal)`

Update details about the service. Note: Changing the country or endpoint URI is not permitted. Instead a new service type should be created and the current one deregistered.

Updating maxAccounts will take effect immediately.

Updating pricePerAccount will take effect after 30 days (priceChangeDelayDays) for existing accounts (to give sufficient notice of any changes) if the price increases. The price change will take effect immediately for all new accounts.

Constraints:

• This method will fail if maxAccounts is being set to a value lower than the current number of connected accounts

deregisterService(did: string, serviceId: string)`

Enable a Verida Infrastructure Operator to deregister a service. There will be a 30 day delay (see deregisterDelayDays) before the service is removed entirely. The service will immediately stop accepting new connections. The service will be flagged as pending removal.

addCredit(did: string)

Allow a Verida Account to deposit VDA tokens as credit to their account. Credit is stored against a given DID. This can be used by both Verida Account users and Verida Infrastructure Operator users.

removeCredit(did: string)

Allow a Verida Account to withdraw VDA tokens that are currently sitting as credit in their account. Tokens will be withdrawn to the account that called this method.

The smart contract will reject the request if, after removing the tokens, the did will have insufficient credit to meet 30 days (minimumDaysCreditPerService) for all connected services.

connectService(did: string, serviceId: string)

Enable a Verida Account to connect and make use of a service provided by a Verida Infrastructure Operator. The Verida Account must deposit sufficient tokens for 30 days (minimumDaysCreditPerService) of utilising the service, calculated based on the pricePerDayPerAccount.

The smart contract will reject the connection if:

• The service is pending de-registration
• The service is has hit its maximum number of connected accounts
• The account didn't deposit sufficient tokens for 30 days of access

disconnectService(did: string, serviceId: string)

Enable a Verida Account to disconnect a service provided by a Verida Infrastructure Operator. The Verida Account will free up tokens previously deposited for utilising the service that can then be removed via removeCredit().

discoverServices(infraType: string (required), serviceType: string, country: string, maxPricePerDay)

Enable easy searching of the available services so users can discover the services they want to select.

distribute()

Distribute credit between all the registered did's based on the connected services.

For each Verida Account Connection credit VDA tokens to the Verida Infrastructure Operator and debit tokens from the Verida Account base on the service pricePerDayPerAccount.

If the Verida Account has insufficient credit the services they have registered are automatically de-registered. There is no guarantee to the order that services are de-registered.

Credit can be added or removed (effectively claiming) via the addCredit() and removeCredit() methods.

Does this method need to be called externally or could it be automatically called every day?

Constraints:

• Ensure this method is only run once per day

DID v blockchain address

Most smart contracts allocate tokens to a blockchain address. In our instance, we need to allocate tokens to a specific DID and only allow those tokens to be withdrawn by that DID.

Data Structures:

InfrastructureType (enum):

[
  "database",
  "storage",
  "messaging",
  "notification"
]

ServiceType (lookup):

[
  "VeridaDatabase": {"type": "database"},
  "VeridaStorage": {"type": "storage"},
  "VeridaMessaging": {"type": "messaging"},
  "VeridaNotification": {"type": "notification"}"
  "TextileDatabase": {"type": "database"},
]

ServiceTypeConfig:

The configuration will depend on the ServiceType.

Config Variables:

These variables can be changed by the contract owner.

• vdaPerDatabaseAccount: How many VDA tokens must be bonded by the Verida Infrastructure Operator to register a database node
• vdaPerMessagingAccount: How many VDA tokens must be bonded by the Verida Infrastructure Operator to register a messaging node
• vdaPerStorageAccount: How many VDA tokens must be bonded by the Verida Infrastructure Operator to register a storage node
• vdaPerNotificationAccount: How many VDA tokens must be bonded by the Verida Infrastructure Operator to register a notification node
• deregisterDelayDays: How many days to delay a service from requesting de-registration to actually being de-registered?
• minimumDaysCreditPerService: How many days credit must a Verida Account maintain for each Verida Account Connection?
• priceChangeDelayDays: How many days to delay price changes for services

Deliverables

• All code created in https://github.com/verida/blockchain-contracts/service-registry folder in this reop
• A smart contract that meets the requirements and provides (at least) the methods above.
• Tests that verify the smart contract is working as expected
• Deployment to Polygon testnet

Future considerations

• Allow infrastructure operators to register multiple services of the same type under the same DID?
• Use a common add / remove credit registry, instead of building into this smart contract?

[tahpot]

I need to scope this during the sprint.

[tahpot]

First draft of scope complete.

Handover call with @BlockchainCrazy95 complete.

[BlockchainCrazy95]

1. registerService(... pricePerDayPerAccount: decimal, ...)

• How can I determine the decimal of pricePerDayPerAccount?
  ex: if decimal is 9 and the pricePerDayPerAccount is 0.1 VDA, I have to call the function with value 100,000,000.
• I think, block number will be stored in the function using block.timestamp.
  Need to reduce the consentBlock parameter.
• Decimal problem is same in updateService function.

2. Need to check the usage of did(:string) value.

3. How can I realize if he is a Verida Infrastructure Operator or Verida Account?

[tahpot]

1. How can I determine the decimal of pricePerDayPerAccount?

pricePerDayPerAccount will be in VDA tokens. The decimal points should match our ERC-20 token.

2. Need to check the usage of did(:string) value

A did is a decentralized identifier. It's a unique reference for an account on the Verida network. You can think of it like a blockchain address, except it's an address on the Verida network.

3. How can I realize if he is a Verida Infrastructure Operator or Verida Account?

I don't think you need to identify them.

I've given them separate names so the user stories make more sense.

[BlockchainCrazy95]

@tahpot, when can config variables be changed?

[BlockchainCrazy95]

• Will finish smart contract and unit test till next Wednesday.

[BlockchainCrazy95]

Here's some questions for Service Registry contract.

• Can ServiceType be deleted later?
• In registerService() function, I think, we need to keep both msg.sender as service register and did.
  Because another account(not the creator) can update service if he knows the did. So we need to keep and check the owner of service.
• When the Verida Infrastructure Operator or Verida Account deposit VDA tokens, Verida get fee from them? Or just staked total amount?
• When the Verida Infrastructure Operator register service, proof is made from client side?
• Verida Infrastructure Operator can also be Verida account?
• When Verida Account add credit, there need to be vdaTokenAmount as a function parameter.
• What is the purpose of distribute() function?
  If this function is needed, the function must be called externally.

Finally, I changed the estimation time from Monday to Wednesday. Is it okay?

[tahpot]

• Can ServiceType be deleted later?

No.

• In registerService() function, I think, we need to keep both msg.sender as service register and did.
  Because another account(not the creator) can update service if he knows the did. So we need to keep and check the owner of service.

No, we don't want to link the msg.sender and the did. The purpose of the proof attribute is to provide a signature that can be verified it was signed by the did. Don't worry about implementing that signature check yet, we can do that at the end. I have another project that has code to make this easy.

• When the Verida Infrastructure Operator or Verida Account deposit VDA tokens, Verida get fee from them? Or just staked total amount?

No fee.

• When the Verida Infrastructure Operator register service, proof is made from client side?

Yes.

• Verida Infrastructure Operator can also be Verida account?

Verida Infrastructure Operator is a type of Verida account being used by an infrastructure provider.

• When Verida Account add credit, there need to be vdaTokenAmount as a function parameter.

Ok.

• What is the purpose of distribute() function?

This function is designed to pay the infrastructure operators and take a fee from the Verida account holder who is using the infrastructure.

It's an automated way to pay for accessing server infrastructure.

If this function is needed, the function must be called externally.

Ok.

Finally, I changed the estimation time from Monday to Wednesday. Is it okay?

Okay.

[BlockchainCrazy95]

updateService(did: string, serviceId: string, maxAccounts: integer, pricePerAccount: decimal)

I have some stuffs to discuss relating to the service update.
Above image shows that the payment methods when we update the pricePerAccount.
There's no problem in first update (day 3). The problem occurs in the second update (day 10) - after 7 days from first update.
As first update delay duration (day 3 ~ day 33) hasn't finished yet, we should decide the second update duration and price.
In this case, we can use above two methods (method1 or method2) for accounts' payment.
Each method has their own pros and cons.
Method1: It's more precise than method 2, but managing state variables might be complicated. Furthermore, if we change the priceChangeDelayDays here, managing state variables might be more and more complicated.
Method2: Managing state variables is easier than method 1.

• Which method should we use?
• If we change priceChangeDelayDays, how can we apply the payment method?

I need to confirm these problems to finish Service Registry contract completely.

[BlockchainCrazy95]

distribute()

We can't iterate all the registered dids on the connected services. It can cause some problems, including gas fee.

For each Verida Account Connection credit VDA tokens to the Verida Infrastructure Operator and debit tokens from the Verida Account base on the service pricePerDayPerAccount.

We can implement this feature as defining claim function. Verida Infrastructure Operator will get VDA tokens using claim function when we need.

If the Verida Account has insufficient credit the services they have registered are automatically de-registered. There is no guarantee to the order that services are de-registered.

We can make view function which check the account availability on service. We can call this view function externally when we need (every day or whenever we need)

function getAvailability(address identity, bytes32 serviceId, bytes signature) public view { ... };

[tahpot]

There's no problem in first update (day 3). The problem occurs in the second update (day 10) - after 7 days from first update.

I suggest we only permit a Verida Infrastructure Operator changing their price once per 30 days. This avoids them changing the price until a previous price change has completed.

We can implement this feature as defining claim function. Verida Infrastructure Operator will get VDA tokens using claim function when we need.

Ideally we can distribute at the end of the day. removeCredit() is effectively a claim function to pull out any unused tokens owned by a DID.

We can make view function which check the account availability on service. We can call this view function externally when we need (every day or whenever we need)

I agree. Let's allow a service availability check. Perhaps we call it checkServiceAvailability()?

However, I think we are best to record the state of a service in the smart contract. ie: service.status = "active|disabled|pendingPayment".

[tahpot]

If we change priceChangeDelayDays, how can we apply the payment method?

priceChangeDelayDays can be changed by the contract owner.

When a price change occurs, the date the price change takes effect is calculated based on the current value of priceChangeDelayDays.

No further price changes can occur until that date has elapsed.

priceChangeDelayDays may change, however the new value won't take effect until the previous price change has been completed.

[tahpot]

proof: string

This will be a common requirement across all our smart contracts.

Don't worry about implementing this yet. We can implement at the end.