Service Daemon exposes an AI application as an API that is accessible through the SingularityNET Network. It handles all interaction with the blockchain for authorization and payment using AGI tokens and passes through API calls to the AI application.
Curretly all payment checks in Daemon are based on fixed pricing
We need to support Dynamic prcing ( i.e compute the price of the service call ) , again this is something best defined by the service provider, however we need to have tool/ support this in Daemon
For example you call a
PackageA.ServiceA.Method1 ( RequestParams) returns (OutPutParms)
Now price to call Method1 depends on what RequestParms are ( ex file size, computational complexity etc) , this is again best determined by the service Provider .
so here is the proposal
Use method Level Options to tell the method to call to determine Price
PS , this method is expected to have the exact same params as the orginal service call method, but will return a standrad message having price . This price will be used by Daemon to do all the validations
Algorithm
Compute the PriceDetermination methods mapped or to be called for service methods when Dynamic pricing is enabled
when a service calls comes in
get the pricing method to call
use the same i/p to invoke this pricing method
get the price to be used
perform validations in Daemon
if all validtions are passed on payment , make the actual service call
syntax = "proto3";
import "google/protobuf/descriptor.proto";
package escrow;
extend google.protobuf.MethodOptions {
EstimatePrice my_method_option = 9999127;
}
//In Order to Support Dynamic Pricing , we need a way to indicate which of the methods will need dynamic pricing Support
//By Dynamic Pricing , the pricing of the service call will be a variable of the inputs passed.
//The Service Provider is best positioned to determine this
//The below standards are to be followed
// 1) The Input Message for the Pricing RPC call will be exactly same as the Input Message of the Service Call
// 2) The Output Message for the Pricing RPC MUST return PriceInCogs.
// 3) Define the name of the RPC method to be called using Method Option EstimatePrice
//helps determine which method to call for dynamic pricing,
//format is of type "packageName/serviceName/MethodName", Example :"/example_service.Calculator/estimate_add"
//Daemon will invoke the actual RPC method , but will invoke the method defined in the method options before
//to determine the price that needs to be charged for this call
message EstimatePrice {
string estimatePriceMethod = 1;
}
//The Value returned by the Pricing call
message PriceInCogs {
uint64 price = 1;
}
As an example
syntax = "proto3";
import "google/protobuf/descriptor.proto";
import "github.com/singnet/snet-daemon/pricing/pricing.proto";// you need to import both these protos
package example_service;
message Numbers {
float a = 1;
float b = 2;
}
message Result {
float value = 1;
}
service Calculator {
rpc add( Numbers) returns (Result) {
option (my_method_option).estimatePriceMethod = "/example_service.Calculator/estimate_add";
}
rpc estimate_add( Numbers) returns (PriceInCogs) {
}
rpc sub(Numbers) returns (Result) {}
rpc mul(Numbers) returns (Result) {}
rpc div(Numbers) returns (Result) {}
}
Curretly all payment checks in Daemon are based on fixed pricing We need to support Dynamic prcing ( i.e compute the price of the service call ) , again this is something best defined by the service provider, however we need to have tool/ support this in Daemon For example you call a PackageA.ServiceA.Method1 ( RequestParams) returns (OutPutParms) Now price to call Method1 depends on what RequestParms are ( ex file size, computational complexity etc) , this is again best determined by the service Provider .
so here is the proposal Use method Level Options to tell the method to call to determine Price PS , this method is expected to have the exact same params as the orginal service call method, but will return a standrad message having price . This price will be used by Daemon to do all the validations
Algorithm
As an example