I've been learning me a Haskell for less than a week and came into this lecture expecting to be totally lost and intimidated. Surprisingly I could follow everything fine and now feel like a future as a blockchain developer is actually achievable for me. It's possible to learn to read and write Haskell at this level very quickly if you are persistent and proceed little by little with the right resources, and don't immediately freak out if something goes over your head. Much has been said about the benefits of using a language like Haskell for blockchain development and the main argument against it is the assumption that people will not want to learn it or will find it too difficult. My experience has showed me this assumption is unfounded and this definitely bodes well for Cardano's future. The FUD surrounding Haskell needs to be dispelled and the best way to do this is to learn it, teach it to others and spread the word about how accessible and rewarding it is to learn.
@@larsbrunjes37 this is true for so many things. As a father, the frustration I feel when teaching my son is alleviated after he firmly grasps the same topic a week later!
Thanks Lars for the great lecture! I have one question. You mention that the hash of the validator is the script address. My concern is that there could be two different validator / scripts that due to hash collision result in the same script address. Is this possible or highly unlikely?
If you have a hash collision for two different codes then your hash function is not that great...They are using the industry standard sha-256 function. Impossible is a big word but it is close.
A lot of blockchain security relies on how astronomically unlikely a hash collision is. If there were hash collisions, two scripts having the same address would be the least of your worries.
But for all simple scripts in the likes of `mkValidator _ _ _ = ()`, the produced compiled code would likely be the same, hence resulting in the same hash? Unless of course some kind of SALT or Timestamp is included as part of the hash.
@@musicalintuition that was my thought as well, some special cases that would result in some constant script adress, e.g. burning tokens or your example
If you write a wallet script that is triggered automatically at a certain point in the future. What happens if the wallet app is deleted before the execution?
1:15:15 So unstableMakeIsData is a silver bullet to create a IsData instance from any data type. Still, in production code, we should use makeIsDataIndexed instead and order the constructors to ensure future compatibility. Is that right?
That's right, yes. And it does not work for ANY data type. It wouldn't work for functions types, for example. Roughly speaking only "serializable" types.
Yes, sure - anybody can use their own off-chain logic if they insist. That's why the on-chain logic has to be designed in a way they only allows "good things" to happen, no matter what the off-chain logic does or does not do.
17:48 "If anybody sends funds to this script address then anybody else can immediately consume that output" I'm a little confused by this. In AlonzoBlue excercise 3, if people sent funds without a Datum hash they could not be spent, and if sent with a hash, then the person consuming that output needed to know a value that had that hash?
Yes, but as the "grab" endpoint demonstrates, it IS indeed possible for arbitrary people to "grab" such outputs. And yes, you need to know the Datum, but you do, because you know the code of the "give" endpoint.
@@larsbrunjes37 Now I'm a little confused by your last statement :) Am I right in saying that the consuming transaction doesn't need the Datum (which is known/supplied by the producing transaction), but rather the code for the Verificator?
@@musicalintuition No, sorry: The PRODUCING transaction only has to produce the HASH of the datum and the HASH of the verifier (which is the script address). The CONSUMING transaction has to include both, datum AND verifier/validator script. But OPTIONALLY, the producing transaction can choose to include the datum, not just its hash.
The Data.hs source that is shown as of minute 7:23, I don't find it under plutus-core/.. but in plutus-tx/src/PlutusTx/Data.hs This is the git log of my plutus src: ea0ca4e9f | 2021-06-26 12:02:14 +0100 | SCP-2435: Use strict environments and make many uses of them strict (#3434)
I see it here: github.com/input-output-hk/plutus/blob/master/plutus-core/plutus-core/src/PlutusCore/Data.hs I used Git commit 81ba78edb1d634a13371397d8c8b19829345ce0d
I've been learning me a Haskell for less than a week and came into this lecture expecting to be totally lost and intimidated. Surprisingly I could follow everything fine and now feel like a future as a blockchain developer is actually achievable for me. It's possible to learn to read and write Haskell at this level very quickly if you are persistent and proceed little by little with the right resources, and don't immediately freak out if something goes over your head. Much has been said about the benefits of using a language like Haskell for blockchain development and the main argument against it is the assumption that people will not want to learn it or will find it too difficult. My experience has showed me this assumption is unfounded and this definitely bodes well for Cardano's future. The FUD surrounding Haskell needs to be dispelled and the best way to do this is to learn it, teach it to others and spread the word about how accessible and rewarding it is to learn.
P.S. thank you Lars for providing us these high quality tutorials on Plutus!
Thank you very much for your comment - I'm really happy to hear about your pleasant experience!
Second time around I understood all of this and found it a great video. Thank you!
Funny, isn't it? things that seem incredibly hard at first are much easier if you give it some time and revisit it later!
@@larsbrunjes37 this is true for so many things. As a father, the frustration I feel when teaching my son is alleviated after he firmly grasps the same topic a week later!
I have to say thanks again for updating the lectures! It is a good way to ease into the development of my own contracts :D
Updating the lectures is almost as much work as creating them in the first place, but I'm happy to hear it's worth my efforts.
Thank you Lars - super helpful presentation. Was able to follow along while completing the homework assignment.
I'm happy to hear that!
Thank you so much Lars ! A wonderful presentation! I would say that second script it's more like a Black-hole ? That a burn? Hehe just kidding !! 😺
Thanks Lars for the great lecture! I have one question. You mention that the hash of the validator is the script address. My concern is that there could be two different validator / scripts that due to hash collision result in the same script address. Is this possible or highly unlikely?
If you have a hash collision for two different codes then your hash function is not that great...They are using the industry standard sha-256 function. Impossible is a big word but it is close.
I guess it is highly unlikely. The account address of ethereum is also hash. If hash collision is not highly unlikely then ethereum is totally unsafe.
A lot of blockchain security relies on how astronomically unlikely a hash collision is. If there were hash collisions, two scripts having the same address would be the least of your worries.
But for all simple scripts in the likes of `mkValidator _ _ _ = ()`, the produced compiled code would likely be the same, hence resulting in the same hash? Unless of course some kind of SALT or Timestamp is included as part of the hash.
@@musicalintuition that was my thought as well, some special cases that would result in some constant script adress, e.g. burning tokens or your example
Thank you again a great lecture!
Thank you so much Lars! 🥳
thank you, will try it out now; cheers
If you write a wallet script that is triggered automatically at a certain point in the future. What happens if the wallet app is deleted before the execution?
1:15:15 So unstableMakeIsData is a silver bullet to create a IsData instance from any data type. Still, in production code, we should use makeIsDataIndexed instead and order the constructors to ensure future compatibility. Is that right?
That's right, yes. And it does not work for ANY data type. It wouldn't work for functions types, for example. Roughly speaking only "serializable" types.
Where can I find the homework files? I'd like to give them a try.
Thanks Lars!
-- | good stuff, Lars ;)
I find one thing confusing, when you say off-chain logic doesn't it mean that it can be meddled with?
Yes, sure - anybody can use their own off-chain logic if they insist. That's why the on-chain logic has to be designed in a way they only allows "good things" to happen, no matter what the off-chain logic does or does not do.
is that a vim editor that you're working in at 13:47?
It sure is! I use VIM as my editor of choice wherever I can.
17:48 "If anybody sends funds to this script address then anybody else can immediately consume that output"
I'm a little confused by this. In AlonzoBlue excercise 3, if people sent funds without a Datum hash they could not be spent, and if sent with a hash, then the person consuming that output needed to know a value that had that hash?
Yes, but as the "grab" endpoint demonstrates, it IS indeed possible for arbitrary people to "grab" such outputs. And yes, you need to know the Datum, but you do, because you know the code of the "give" endpoint.
@@larsbrunjes37 Ah, ofcourse 😄 Thank you!
@@larsbrunjes37 Now I'm a little confused by your last statement :) Am I right in saying that the consuming transaction doesn't need the Datum (which is known/supplied by the producing transaction), but rather the code for the Verificator?
@@musicalintuition No, sorry: The PRODUCING transaction only has to produce the HASH of the datum and the HASH of the verifier (which is the script address). The CONSUMING transaction has to include both, datum AND verifier/validator script.
But OPTIONALLY, the producing transaction can choose to include the datum, not just its hash.
@@larsbrunjes37 Ah makes perfect sense! Thank you!!
can anyone tell me what the "@" means?
It's a "type application" - it specifies at which type to use a generic function.
The Data.hs source that is shown as of minute 7:23, I don't find it under plutus-core/.. but in plutus-tx/src/PlutusTx/Data.hs
This is the git log of my plutus src: ea0ca4e9f | 2021-06-26 12:02:14 +0100 | SCP-2435: Use strict environments and make many uses of them strict (#3434)
I see it here: github.com/input-output-hk/plutus/blob/master/plutus-core/plutus-core/src/PlutusCore/Data.hs
I used Git commit 81ba78edb1d634a13371397d8c8b19829345ce0d
This is what you get when boomers get bored! Gotta invent new, more convoluted things when traditional languages get too ez. 🤣