In the last video we spoke about the process of deploying a contract to a theory network.
I want to mention something that seems kind of interesting at this point in the course if you recall
when we spoke about sending money from one person to another we had to create a transaction.
And when we sent money from one person to another that modified the data that was stored on the block
chain like think about it there's probably on the block chain some record that says My account has 100
either and your account has zero or whatever it might be.
And when we submit that transaction and then updated my balance to maybe 99.
And your balance up to 1 in the last video when we spoke about creating a transaction we are been creating
a contract.
We had said that to create that contract and to deploy it to the network.
We had to Smiddy transaction.
And so in theory that's probably updating some data in the block chain as well that deployed contract
now has to be stored in the block chain and we need some record in there that says hey here's what the
current value of messages.
So the common running theme here appears to be that any time that we want to update any data on the
block chain we have to submit a transaction.
And this is a rule that's going to hold true for Ousley.
Everything we do with a theory.
Anytime we want to change any data that gets stored on the block chain we are going to have to submit
a transaction.
And what's more.
Not only do we have to submit that transaction but we also have to wait for it to be mined or to go
through that proof of work algorithm and that can take anywhere from 10 to 30 seconds to execute.
So any time you're changing any data we have to submit a transaction and we have to wait for the transaction
to be approved before we can say confidently hey the data stored on the block chain has been updated.
Now why is this important.
What am I getting at.
Well I want to remind you of something kind of interesting.
Remember these two functions down here.
We've got our message function and the set message function so message retrieves a value and sent message
updates of value message is a piece of piece of data that is being stored on the block chain.
It's stored within our contract.
And so if we are saying that updating any value on the block chain involves a transaction what does
that mean about set message right here when we try to run said message.
Does that involve a transaction.
Essentially if we think about it set message is changing the block chain so it must involve a transaction.
But what's even more interesting is get message doesn't change anything at all.
So these are two functions.
What is the difference between the two if this one has to involve a transaction.
And this one doesn't.
Well this is a very long introduction from me to introduce a concept of the different ways in which
we run functions on our contracts.
I'm sorry about the three minute introduction there but I really want to build up the suspense.
So here's the deal.
There are two ways in which we invoke functions that belong to our contracts.
These two ways will result in very different behavior.
So we are literally talking about the different ways in which we can execute the function set message
or the function to retrieve the message value right here.
The first way in which we can call a function is called literally calling a function when we call a
function it cannot modify the contract state at all.
A good example of this will be our message function down here.
This does not modify our contracts data.
In fact if you hover over this button right underneath your cursor there you'll see a little pop up
and it says Message dash call.
Because that means we are literally calling this function so I can click it.
That results in a call and we instantly get back some return value that appears right here.
Calling a function can return data as we just saw one second ago.
So right here look here is our return value says Hi there.
When we call a function it runs instantly because it doesn't involve a transaction it doesn't need to
be mined and finally calling a function is free to do so every single time that we call message right
here instantaneous free pretty much behaves the way that you would expect any programming language function
call to behave.
Calling a function really is the way that you expect it to behave where things get really interesting
is when we start to want to modify the data that is stored in our contract.
So when we want to modify any data that is stored in our contract we are not going to be calling the
function any more.
Now throughout this course I might say to you like oh yeah we're going to call this function.
If I say that usually it's out of habit.
You know you're honestly making the difference between these two ways of invoking a function you know
labeling this as calling a function wasn't the best pick because we say that invoking functions referred
to as calling in just about every other programming language there is.
So I might make some verbal typos as we go throughout the course but essentially any time that we want
to invoke a function that is intended to change some data we are going to be invoking it by sending
a transaction to our contract instance that targets a specific function.
When we do this we can modify a contract's data.
And in fact if you look down at set message right here that has the purpose of modifying our contract
data it's modifying message right here.
If you hover over the button you'll notice it says set message dash transact transact meaning we're
going to create a transaction that targets this function.
Now there's some very important gotchas here and these are some of the gotchas that I mentioned about
solidity earlier on.
There are other gotchas but these are some of the very biggest ones that we need to be aware of.
First any time that we submit a transaction to the network it takes time to be processed.
Remember any time that we use like when we sent money from one account to another using the ring be
falsely over here earlier this took about 30 seconds to be executed.
And we now know that it took about 15 seconds for the proof of work algorithm and then maybe another
10 seconds or something for that to be confirmed by other nodes and then maybe some other seconds to
return an answer back to our our site here.
So any time we are trying to update a value any time on any contract it's going to take somewhere from
15 to 30 seconds to actually execute and give us a notification back that says hey everything looks
good.
Secondly whenever we send a transaction to a function that returns the transaction hash Szilard call
that right here we see right here here's your transaction ID.
This was a transaction hash.
So whenever we send the transaction to a function we get a response back of Hey here's something that
identifies the transaction that occurs or that you just submitted excuse me we do not get a return value
back even if the function that we write has some something inside of it that says that we're trying
to return a value.
So for example if I changed the set message function right here if I change set message can say after
updating message I want to return message and then I also update the function signature to save returns.
String noticed so solidity the whole idea here remix is not really complaining about what I just did.
It's not saying hey you're trying to return a value here but this is a function that you're going to
invoke with the transaction.
So this is very surprising behavior.
This is the behavior of solidity.
It is behaving in a way that you probably would not expect.
So even though it appears that we can invoke this function and get a value back that is not the case
because since we want to update some data in the contract we have to send a transaction.
And that is not instantaneous.
We don't get the value back.
We get back the transaction hash.
All right now I'm going to delete that stuff.
I know this is a long video but there's you know this is some very important gotchas that I know are
going to come up later.
These are gotchas that I just guarantee you are going to come up.
So there are things we have to talk about.
So last one I wanted to discuss here is the fact that sending a transaction to a function costs money.
This is something that we'll talk about much more in a video or two.
And this is something that we've kind of held out discussing at this point in the course so far but
Sonia trangia transaction to a function does cost money and I can prove that to you through the Remax
tool.
So if we go back over to the run tab here.
So here's is.
I'm going to make sure I still have my javascript VM selected and I'm going to select an account that
appears to still have 100 ethers inside of it.
So make sure you select it.
An account that has 100 either.
Then I'm going to go down to the bottom where I've got my deployed contract right here and I'm going
to send a message saying I'm going to invoke set message and attempt to update a value stored in the
block chain.
So I'll say greetings and then I'll run it.
It gets processed.
But if you look back up at the account balance you'll notice that it's now gone down to ninety nine
point nine and then nine blah blah blah either.
So it costs very little either but it did cost money to update the value here.
Now there might be something that you are very confused about right now.
When I called sent message just a second ago that touches back on the fact that I just mentioned that
it takes time to execute.
So I'm seeing right now hey it takes time to execute anything that updates data.
However it appears that in remix whenever we call set message like you know let's do something else
here.
Whenever I clicked that it sure appears to me to be instantaneous right.
Like that looks awfully instantaneous.
The difference here is that it takes time to execute these transactions when we are on public networks.
So on the main theory and network on Roberston on Koven on Rinck be on all these public test networks.
There is a block time of 15 seconds however on any test network like the one that you and I are using
right now this simulated local network running inside the browser.
The transaction block time or zoomy just the block time gets tuned way way way way way down to the near
instantaneous.
So this is a huge gotcha.
The biggest gotcha.
Like I got my hands on my head in real life right now.
I got to tell you I just told such a gotcha like a mind blowing interesting thing because any time you
go in look at a tutorial around solidity and theory and contracts and all this stuff it's always written
using these networks that instantly process transactions and so you will see a tremendous amount of
content out there around building a theory and apps that are all set up assuming that these transactions
get approved instantaneously because they are running these network or these transactions on local test
networks that process transactions instantly.
However in the real world as our users actually interact with these apps that you and I are going to
build anytime we try to update some data we have to wait that 15 to 30 seconds for that data to be processed.
And this is completely shocking.
I want you to think about it for a second.
Imagine that you are building let's say Twitter like let's go look at Twitter right now.
So when we are running let's imagine that we were building Twitter on top of the year in block chain.
If we were developing our application and while developing it we were using a local network and let's
say I entered in like a new tweet right here and then clicked on tweet on a local test network.
Usually they are configured to instantly process these transactions exactly as you see right down here
with a set message button.
When I click this it instantly processes the transaction.
But in the real world like if we were actually working with Twitter with a real a theory network like
the main network when I clicked on tweet right here it would take 15 to 20 seconds for that to actually
be processed.
And so whenever we build these theory apps we have to keep that in mind.
We have to make sure that when user like clicks the button we show something that says hey you just
committed a transaction this is going to take like 15 seconds to process.
Please hold on while that runs and I find that this is actually a really big shock to people who are
first getting involved in a theorem because usually you and I are used to changing data like making
a tweet clicking tweet and then instantaneously poof.
There it is.
Get it got written to some database but with the way that theory works we have to wait for that.
BLOCK time to actually see the transaction confirmed and reflect the new value in the block chain.
All right so thats my rant about transaction times.
The point here is that when we are running these test networks locally we get unrealistic times to complete
transactions.
We do that because hey it makes it easier for you and I to develop things.
But the flip side is that usually you just need to be aware that your development environment is very
different from the real environment.
And thats why by the way I've said so constantly that we're going to be using the ring B test network
so that when you and I start building actual applications we see that big delay we like.
I personally I want to see that 10 second delay or 15 seconds whatever it is that it takes to write
data to the network so that I make sure that I build my application in such a way that users are informed
that hey this writing action takes 15 seconds or whatever it might be.
Are you for real.
I'm done.
Let's pause right here.
This was probably a lot more than you wanted to hear.
So let's continue the next video.
We'll do a quick recap on Runyon's contract functions and we'll talk about what all this like cost money
to invoke functions means.
So I'll see you in just a minute.