Topic: How to calculate fee for Smart Contract execution (Read 6308 times)

colin012 · « **Reply #20 on:** August 12, 2014, 03:36:30 pm »

Quote from: Come-from-Beyond on August 12, 2014, 05:47:19 am

Quote from: colin012 on August 11, 2014, 11:28:30 pm
As far as collusion goes, if the majority of nodes colluded, then Smart Contracts are the least of our worries as the entire blockchain could be rewritten.

U forgot 90% attack protection. But we'll indeed have problems with colluded nodes if ask them to measure SC execution time, coz they may report time that is 100 times lower and in the result we'll get stalled network.

I see your point. :/

ChuckOne · « **Reply #21 on:** August 12, 2014, 04:32:51 pm »

Quote from: Come-from-Beyond on August 10, 2014, 09:04:11 pm

Quote from: nexern on August 10, 2014, 08:52:03 pm
hmmm..., what if 'heavy' contracts are needed to solve complex problems and the majority nodes are tiny and therefore skipping
them without any manual correction to prevent this? moreover, 'heavy' is relative/individual for each node with different hardware.
not sure an general skip mechanism provides the scaling-margin and flexibility needed to run complex contracts which we can't
anticipate now (or do you mean the absolute execution time per contract or per node in sum?)

A big SC can be splitted into smaller parts. Also main contract of a smart contract is not to solve complex problems.

I think that is a very important statement here. That should be made a guideline for SC development.

nexern · « **Reply #22 on:** August 12, 2014, 05:08:21 pm »

could be. as long you can ensure atomic operations over those splits, to prevent leaving your cascaded queries->resultsets/triggers inconsistent.
while transactions->commmits/rollbacks are used to solve this on a central rdbms, i am not sure this can be easily mapped with a decentralized
standard db, where the db is just a simple datasink (from nodeview)

iirc erlang (mnesia) is solving this with locks on temporary tables and callbacks, wrapped into a multiphase commit protocol.
but well, since i have no concrete idea how this sql based sc will looks like there i a good chance i am approaching this much too complicated.

ChuckOne · « **Reply #23 on:** August 13, 2014, 10:14:17 am »

Quote from: nexern on August 12, 2014, 05:08:21 pm

could be. as long you can ensure atomic operations over those splits, to prevent leaving your cascaded queries->resultsets/triggers inconsistent.
while transactions->commmits/rollbacks are used to solve this on a central rdbms, i am not sure this can be easily mapped with a decentralized
standard db, where the db is just a simple datasink (from nodeview)

iirc erlang (mnesia) is solving this with locks on temporary tables and callbacks, wrapped into a multiphase commit protocol.
but well, since i have no concrete idea how this sql based sc will looks like there i a good chance i am approaching this much too complicated.

SQL SELECT will simply create new transactions. Each row in the result table is a new transaction that gets handled like regular ones.

ChuckOne · « **Reply #24 on:** August 13, 2014, 10:20:20 am »

About costs:

Should not input size, runtime and output size be considered when determining how much to pay for an SC execution?

nexern · « **Reply #25 on:** August 13, 2014, 11:11:11 am »

Quote from: ChuckOne on August 13, 2014, 10:14:17 am

SQL SELECT will simply create new transactions. Each row in the result table is a new transaction that gets handled like regular ones.

hm...a select doesn't create any new transaction, don't understand what you mean here.
i am talking about to wrap several atomic write operations (splitted contract->select->update/insert)
into one commited sql transaction. don't mix the sql transaction with a blockchain transaction.

wesley · « **Reply #26 on:** August 13, 2014, 11:12:27 am »

The SELECT returns the transactions to be created.

nexern · « **Reply #27 on:** August 13, 2014, 11:17:55 am »

Quote from: wesleyh on August 13, 2014, 11:12:27 am

The SELECT returns the transactions to be created.

a select simple returns DATA which can be used to CREATE a new blockchain transaction
and this create process is the point, not the data fetching.

ChuckOne · « **Reply #28 on:** August 13, 2014, 10:29:33 pm »

Quote from: nexern on August 13, 2014, 11:17:55 am

a select simple returns DATA which can be used to CREATE a new blockchain transaction
and this create process is the point, not the data fetching.

What is the issue? CfB's idea mirrors SPARQL's construct statement http://www.w3.org/TR/rdf-sparql-query/#construct

So, what is the point?

nexern · « **Reply #29 on:** August 13, 2014, 11:03:45 pm »

Quote from: ChuckOne on August 13, 2014, 10:29:33 pm

Quote from: nexern on August 13, 2014, 11:17:55 am
a select simple returns DATA which can be used to CREATE a new blockchain transaction
and this create process is the point, not the data fetching.

What is the issue? CfB's idea mirrors SPARQL's construct statement http://www.w3.org/TR/rdf-sparql-query/#construct

So, what is the point?

interesting i thought i had read cfb is using/mapping plain SQL 92.
anyway, the point is - spliting contracts could breaks atomicity, because they are running serial and isolated and not within a single call and bounded scope.
don't know if SPARQL provides a rollback for uncompleted inserts or updates sequences but if not, the point is still valid.

ChuckOne · « **Reply #30 on:** August 14, 2014, 07:15:22 am »

Quote from: nexern on August 13, 2014, 11:03:45 pm

Quote from: ChuckOne on August 13, 2014, 10:29:33 pm
Quote from: nexern on August 13, 2014, 11:17:55 am
a select simple returns DATA which can be used to CREATE a new blockchain transaction
and this create process is the point, not the data fetching.

What is the issue? CfB's idea mirrors SPARQL's construct statement http://www.w3.org/TR/rdf-sparql-query/#construct

So, what is the point?

interesting i thought i had read cfb is using/mapping plain SQL 92.
anyway, the point is - spliting contracts could breaks atomicity, because they are running serial and isolated and not within a single call and bounded scope.
don't know if SPARQL provides a rollback for uncompleted inserts or updates sequences but if not, the point is still valid.

Well, first it is LIKE SPARQL CONSTRUCT. I thought CfB, though, strive for basic SQL syntax.

Second, yes atomicity is important. Issue here (https://nxtforum.org/smart-contracts/transactions-without-signature/msg81191/#msg81191) goes hand in hand with your question.

When there is no materialization how to check where the execution of an SC ended AND therefore prevent execution of subsequent SCs? I think CfB will need to think about that.

Switch to ArdorForum

News:

Author Topic: How to calculate fee for Smart Contract execution (Read 6308 times)

colin012

Re: How to calculate fee for Smart Contract execution

ChuckOne

Re: How to calculate fee for Smart Contract execution

nexern

Re: How to calculate fee for Smart Contract execution

ChuckOne

Re: How to calculate fee for Smart Contract execution

ChuckOne

Re: How to calculate fee for Smart Contract execution

nexern

Re: How to calculate fee for Smart Contract execution

wesley

Re: How to calculate fee for Smart Contract execution

nexern

Re: How to calculate fee for Smart Contract execution

ChuckOne

Re: How to calculate fee for Smart Contract execution

nexern

Re: How to calculate fee for Smart Contract execution

ChuckOne

Re: How to calculate fee for Smart Contract execution