Why transactions/contracts aren't priced/tracked based on computer running time
Clash Royale CLAN TAG#URR8PPP
Amazon AWS and Google Cloud all base their pricing off of, among a few other things, the amount of compute and storage used. For compute, it's based on time, how much time the computer runs. This is very general and abstracts away the need to, for example, count how many times each Assembly instruction is invoked and with which operands. This would significantly interrupt performance if they did it that way, but it seems that the blockchain technologies all went the path of monitoring the individual actions/operations either through transactions directly or Smart Contracts in the case of Ethereum.
So basically I'm wondering why this is, why it wasn't decided to just base everything off compute time and storage (and bandwidth I guess, but mainly focusing on compute time here). This way a transaction would just have to have a start and end timestamp and wouldn't have to really serialize anything, which would mean you could monitor everything in detail pretty much. Wondering why it was done differently.
transactions contract-design database
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
add a comment |
Amazon AWS and Google Cloud all base their pricing off of, among a few other things, the amount of compute and storage used. For compute, it's based on time, how much time the computer runs. This is very general and abstracts away the need to, for example, count how many times each Assembly instruction is invoked and with which operands. This would significantly interrupt performance if they did it that way, but it seems that the blockchain technologies all went the path of monitoring the individual actions/operations either through transactions directly or Smart Contracts in the case of Ethereum.
So basically I'm wondering why this is, why it wasn't decided to just base everything off compute time and storage (and bandwidth I guess, but mainly focusing on compute time here). This way a transaction would just have to have a start and end timestamp and wouldn't have to really serialize anything, which would mean you could monitor everything in detail pretty much. Wondering why it was done differently.
transactions contract-design database
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
add a comment |
Amazon AWS and Google Cloud all base their pricing off of, among a few other things, the amount of compute and storage used. For compute, it's based on time, how much time the computer runs. This is very general and abstracts away the need to, for example, count how many times each Assembly instruction is invoked and with which operands. This would significantly interrupt performance if they did it that way, but it seems that the blockchain technologies all went the path of monitoring the individual actions/operations either through transactions directly or Smart Contracts in the case of Ethereum.
So basically I'm wondering why this is, why it wasn't decided to just base everything off compute time and storage (and bandwidth I guess, but mainly focusing on compute time here). This way a transaction would just have to have a start and end timestamp and wouldn't have to really serialize anything, which would mean you could monitor everything in detail pretty much. Wondering why it was done differently.
transactions contract-design database
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
Amazon AWS and Google Cloud all base their pricing off of, among a few other things, the amount of compute and storage used. For compute, it's based on time, how much time the computer runs. This is very general and abstracts away the need to, for example, count how many times each Assembly instruction is invoked and with which operands. This would significantly interrupt performance if they did it that way, but it seems that the blockchain technologies all went the path of monitoring the individual actions/operations either through transactions directly or Smart Contracts in the case of Ethereum.
So basically I'm wondering why this is, why it wasn't decided to just base everything off compute time and storage (and bandwidth I guess, but mainly focusing on compute time here). This way a transaction would just have to have a start and end timestamp and wouldn't have to really serialize anything, which would mean you could monitor everything in detail pretty much. Wondering why it was done differently.
transactions contract-design database
transactions contract-design database
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
asked Feb 17 at 14:01
Lance PollardLance Pollard
1256
1256
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Ethereum basically does base its pricing on computing time and storage costs. Plus bandwidth (transaction cost). All instructions have an associated gas cost. So, as I see it, Ethereum is more precise in its calculations but it's basically based on very similar principles.
As to the why Ethereum does it this way... I can think of at least a few reasons:
1) If it was simply based on computing time different nodes would have different gas costs. A faster node would compute everything faster. So could a faster node include more transaction in a block? This would all lead to centralization - a faster node would gain more gas rewards and therefore it'd be more beneficial to have a fast node. Slower nodes would slowly die out.
2) Who would measure the compute time and how? The network itself has no idea how long it takes for a node to compute something. It would obviously not be a good idea to simply let the node tell how long the processing took (and get paid accordingly). It would be easy for nodes to cheat in various ways.
3) There are still the other costs, such as storage and bandwidth (transactions). They are priced based on known static instructor costs. It would probably get difficult to combine different calculation methods.
All in all, different pricing models might easily lead to centralization in different ways. One of the main ideas of Ethereum is to allow different nodes to participate in a fair way. The more the system favors certain types of nodes, the less secure it would get.
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "642"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fethereum.stackexchange.com%2fquestions%2f67199%2fwhy-transactions-contracts-arent-priced-tracked-based-on-computer-running-time%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ethereum basically does base its pricing on computing time and storage costs. Plus bandwidth (transaction cost). All instructions have an associated gas cost. So, as I see it, Ethereum is more precise in its calculations but it's basically based on very similar principles.
As to the why Ethereum does it this way... I can think of at least a few reasons:
1) If it was simply based on computing time different nodes would have different gas costs. A faster node would compute everything faster. So could a faster node include more transaction in a block? This would all lead to centralization - a faster node would gain more gas rewards and therefore it'd be more beneficial to have a fast node. Slower nodes would slowly die out.
2) Who would measure the compute time and how? The network itself has no idea how long it takes for a node to compute something. It would obviously not be a good idea to simply let the node tell how long the processing took (and get paid accordingly). It would be easy for nodes to cheat in various ways.
3) There are still the other costs, such as storage and bandwidth (transactions). They are priced based on known static instructor costs. It would probably get difficult to combine different calculation methods.
All in all, different pricing models might easily lead to centralization in different ways. One of the main ideas of Ethereum is to allow different nodes to participate in a fair way. The more the system favors certain types of nodes, the less secure it would get.
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
add a comment |
Ethereum basically does base its pricing on computing time and storage costs. Plus bandwidth (transaction cost). All instructions have an associated gas cost. So, as I see it, Ethereum is more precise in its calculations but it's basically based on very similar principles.
As to the why Ethereum does it this way... I can think of at least a few reasons:
1) If it was simply based on computing time different nodes would have different gas costs. A faster node would compute everything faster. So could a faster node include more transaction in a block? This would all lead to centralization - a faster node would gain more gas rewards and therefore it'd be more beneficial to have a fast node. Slower nodes would slowly die out.
2) Who would measure the compute time and how? The network itself has no idea how long it takes for a node to compute something. It would obviously not be a good idea to simply let the node tell how long the processing took (and get paid accordingly). It would be easy for nodes to cheat in various ways.
3) There are still the other costs, such as storage and bandwidth (transactions). They are priced based on known static instructor costs. It would probably get difficult to combine different calculation methods.
All in all, different pricing models might easily lead to centralization in different ways. One of the main ideas of Ethereum is to allow different nodes to participate in a fair way. The more the system favors certain types of nodes, the less secure it would get.
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
add a comment |
Ethereum basically does base its pricing on computing time and storage costs. Plus bandwidth (transaction cost). All instructions have an associated gas cost. So, as I see it, Ethereum is more precise in its calculations but it's basically based on very similar principles.
As to the why Ethereum does it this way... I can think of at least a few reasons:
1) If it was simply based on computing time different nodes would have different gas costs. A faster node would compute everything faster. So could a faster node include more transaction in a block? This would all lead to centralization - a faster node would gain more gas rewards and therefore it'd be more beneficial to have a fast node. Slower nodes would slowly die out.
2) Who would measure the compute time and how? The network itself has no idea how long it takes for a node to compute something. It would obviously not be a good idea to simply let the node tell how long the processing took (and get paid accordingly). It would be easy for nodes to cheat in various ways.
3) There are still the other costs, such as storage and bandwidth (transactions). They are priced based on known static instructor costs. It would probably get difficult to combine different calculation methods.
All in all, different pricing models might easily lead to centralization in different ways. One of the main ideas of Ethereum is to allow different nodes to participate in a fair way. The more the system favors certain types of nodes, the less secure it would get.
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
Ethereum basically does base its pricing on computing time and storage costs. Plus bandwidth (transaction cost). All instructions have an associated gas cost. So, as I see it, Ethereum is more precise in its calculations but it's basically based on very similar principles.
As to the why Ethereum does it this way... I can think of at least a few reasons:
1) If it was simply based on computing time different nodes would have different gas costs. A faster node would compute everything faster. So could a faster node include more transaction in a block? This would all lead to centralization - a faster node would gain more gas rewards and therefore it'd be more beneficial to have a fast node. Slower nodes would slowly die out.
2) Who would measure the compute time and how? The network itself has no idea how long it takes for a node to compute something. It would obviously not be a good idea to simply let the node tell how long the processing took (and get paid accordingly). It would be easy for nodes to cheat in various ways.
3) There are still the other costs, such as storage and bandwidth (transactions). They are priced based on known static instructor costs. It would probably get difficult to combine different calculation methods.
All in all, different pricing models might easily lead to centralization in different ways. One of the main ideas of Ethereum is to allow different nodes to participate in a fair way. The more the system favors certain types of nodes, the less secure it would get.
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
answered Feb 17 at 15:16
Lauri PeltonenLauri Peltonen
5,7582525
5,7582525
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
add a comment |
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Awesome, good to know! I thought it would come as a performance hit to do it this way. Wondering if you could point me to the source code for Ethereum that invokes a contract's functions one by one, and then does the charge. That would be really interesting to see!
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Good point on (1), same with (2).
– Lance Pollard
Feb 17 at 15:26
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Sorry, I'm not familiar with the code so can't point you forward with that.
– Lauri Peltonen
Feb 17 at 15:31
Here we go.
– Lance Pollard
Feb 17 at 15:39
Here we go.
– Lance Pollard
Feb 17 at 15:39
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
This say's it's not based on compute time but is instead based on individual instructions' evaluation.
– Lance Pollard
Feb 17 at 15:42
add a comment |
Thanks for contributing an answer to Ethereum Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fethereum.stackexchange.com%2fquestions%2f67199%2fwhy-transactions-contracts-arent-priced-tracked-based-on-computer-running-time%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown