Hello and welcome to the session on socket interface part 2. At the end of this session students will be able to introduce socket interfaces and list some common functions in this interface. The interaction between a process and the operating system is done through a list of predefined functions. Here in this session we are going to discuss some functions which are going to be combined to create a processes. The first function is socket function. The operating system does not create a socket until instructed by the process. The process needs to use a socket function call to create a socket. The prototype is shown here. A call to this function creates a socket but only three fields in the socket structure family, type and protocol. If the call is successful the function returns a unique socket descriptor SOCFD which is a non-negative integer that can be used to refer to the socket in other calls. If the call is not successful the operating system returns minus 1, the bind function. The socket function fills the fields in the socket partially. To bind the socket to the local computer and local port the bind function needs to be called. The bind function fills the value of the local socket address and if it returns minus 1 if binding fails. The prototype is shown here. In this prototype the SOCFD is the value of the socket descriptor returned from the socket function call. Socket address is a pointer to a socket address that needs to help and the address length is the length of the socket address. The connect function. The connect function is used to add a remote socket address to the socket structure. If it returns minus 1 if the connection fails. The prototype is shown here. The argument is same except that the second and third argument defines the remote address instead of local one. The listen function. The listen function. The listen function is called only by the TCP server. After TCP has created and binding it must inform the operating system that a socket is ready for receiving client requests. The accept function. The accept function is used by a server to inform TCP that it is ready to receive connections from clients. And this function returns minus 1 if it fails. The prototype is shown here. The last two arguments are pointers to address and to length. The accept function is a blocking function that when called blocks itself until the connection is made by a client. The accept function then gets the client socket address and the address length and passes it to the server process to be used to access the fork function. The fork function is used by a process to duplicate a process. The process that calls the fork function is referred to as a parent process and a process which is going to be created. The duplicate is called the child process. And here it is interesting that the fork process is called once but it returns twice. In the parent process the return value is a positive integer. In the child process the return value is 0 if there is an error. The fork function returns minus 1 if it fails. After the fork two processes are running concurrently and the CPU gives running time to each process alternatively. Send and receive function. The send function is used by a process to send data to another process running on a remote machine. The receive function is used by a process to receive data from another process running on a remote machine. The functions assume that there is already an open connection between two machines and it can only be used by TCP or may other protocol like HTTP. These functions returns the number of bytes sent or received. Here the FD is a socket descriptor. Send buffer is a pointer to the buffer where data to be sent have been stored. Receive buffer is a pointer to the buffer where the data is issued to be stored. Send bytes is the size of the data to be sent or received. This function returns the number of actual bytes sent or received if successful otherwise minus 1 if there is an error. Send to and receive from functions. The send to function is used by a process to send data to a remote process using services of UDP. The receive from function is used by a process to receive data from a remote process using a services of UDP. UDP is a connectionless protocol. One of the argument defines the remote socket address. Here the socket FD is the socket descriptor, buffer is a pointer to the buffer where the data to be sent or the data to be received is stored and the buffer length is the length of the buffer. The value of the flag can be non-zero but here we are going to set it as 0 for our simple programs. These functions return the number of bytes sent or received if successful and minus 1 if there is an error. The close function is used by a process to close a socket. The socket FD is not valid after calling this function. The socket returns an integer 0 for success and minus 1 for an error by ordering function. The information in computer is stored host byte order which can be a little indian in which the little end byte is stored in the starting address and big indian which is a big end byte stored in a starting address. Network programming needs data and other piece of information to be in network byte order in which the big indian two functions are designed for this particular purpose. The h turns host to network short which changes a short 16 bit value to a network byte order and h to nl host to network long which does the same for a long 32 bit value. There are also two functions that do exactly n to hs and n to hl. The prototype is shown here. The memory management function at the end we need some functions to manage values stored in the memory and there are three common memory functions. The first function memset that is memory set is used to set a specified number of bytes in the memory defined by the destination pointer. The second function memory copy is used to copy a specified number of bytes from a part of a memory to another part of memory that is from source to destination. The third function memory compare which is used to compare two sets of bytes starting from pointer 1 and pointer 2 and the result is 0 if two sets are equal. It is less than 0 if the first set is smaller than the second and it is greater than 0 if the first set is larger than the second address conversion functions. So generally what happens we normally work with 32 bit IP address which is in a dotted decimal format. Then we want to store the address in socket. We need to change it to the number and there are two functions which are used to convert an address from a presentation to a number and vice versa. I need ptern presentation to number and I need n to p number to presentation. Header files to use just describe the functions we need a set of header files and we define these header files in a separate file okay in header files dot h. We include the files in our programs to avoid including long list of the header files. The header files which are going to be used in the programs are shown here pause the video think and answer the answer is C here is the reference thank you.


So there's been a lot of excitement about ProgPowl. And what is ProgPowl? Well, it's a programmatic proof of work. And we're going to be tackling all your questions and answers today. This will be sort of a medium level expertise presentation, so not too technical, but not too generic. And if you really want to go in a deeper dive, you should check out the official GitHub repo with the official code and the white paper, as well as our medium accounts. But first, a little bit about the team. So too many people put an emphasis on the people behind algorithms or work, which is highly amusing to me, especially considering that cryptocurrency is all about no trust. But hey, I learned from the first time when we released ProgPowl that you actually have to do these disclaimers. So I figure we have to do a disclosure on who we are. So ProgPowl is made by three people, if deaf, else. I am Ms. If. I am currently Chief Technology Officer of Core Scientific. Core Scientific is an artificial intelligence and blockchain infrastructure and hosting company. I'm also the founder of the minority group who is responsible for our fantastic graphics today. And I'm also ex-genesis mining, the world's leading hashing power provider. And then we also have Mr. Deaf. Mr. Deaf is an experienced systems engineer. He's a blockchain enthusiast. And I like to call him a professional catherter, because that's pretty much what 24 hours of his job consists of. And then we have Mr. Else. So Mr. Else is quite an experienced semiconductor engineer. He has over 10 years of experience working in this space. And he is also an experienced GPU architect. And he loves ProgPowl. But not the ProgPowl we're all familiar with. He loves this ProgPowl. And together, we are if deaf, else. So what is ProgPowl? Well, as I said before, it's a programmable or programmatic proof of work. Or as we like to say, a GPU-tuned extension of at hash. It's also sometimes called ProgPowl or ProgWOWl after this little guy. Our little hero from Star Wars, The Lost Jedi. And it also takes its roots from the word programmatic. Now, I quite like programmatic, because it's a great way to explain algorithms. Algorithms are actually very musical. Every algorithm has a beat. And optimization, when we talk about optimization of software or hardware, it's all about matching the beat of an algorithm to the beat of a hardware. So at hash, I like to say, is a little like Trapcore. Minero is like Dubstep. Zcash is a little like Rock. And these beats, like I said, they need to synchronize with the hardware itself. So let's do a big deep dive. Right now, why was ProgPowl created? Well, today there's kind of a problem with algorithms. You see, traditionally, algorithms are designed by software engineers. Now, you might be asking, what's wrong with that? Well, would you want your hardware designed by a software engineer? The answer is no, because that's actually how you end up with things like these, the Windows phone. So we always talk about how you need to have people who are experts left to do the things that they're an expert in. Hardware engineers should tune for hardware. Software engineers should tune for application layers. That's the crux of the problem today, and how we get fixed function hardware, or in this case, A6. And proof of work has traditionally taken an algorithm that's fixed and tried to shoehorn in the hardware to make it efficient at executing it. But that leaves many unused parts of the hardware that you can just shave off or you can get rid of. Instead, ProgPowl flips this paradigm. We take the hardware, already existing, and we modify an algorithm to match it. Because an efficient algorithm for proof of work means hardware needs to match access patterns and available space of that hardware. Now, I know what everyone right now is waiting for me to say, given how vocal I am about ASIC resistance, but I hate to say it. ASIC resistance is a fallacy. There's no such thing.  Proof of work requires some form of an ASIC to do work, be it a CPU, a GPU, an FPGA, or a mining ASIC. And guess what? Oops, they're all ASICs. They're all built using the exact same fabs, the exact same technologies, the exact same materials. The difference, however, in this hardware is the class of algorithms they're designed to execute efficiently and that they're optimized for. So generally, when they say ASIC resistance, what they're meaning is centralization resistance. And we can dive into why that's important in the breakout session, but there's my statement on ASIC resistance. It doesn't actually exist. So why does hardware actually matter? Why do we care about hardware with Ethereum? Well, for the time being, hardware actually defines your user base. And no blockchain is suited for all user bases, just like no application is suited for all customers. GPUs, they're for the common folk. They're readily available, they're flexible, they're adaptable, they're quite cheap, and pretty much everyone has one today. Look at your phones, you all have a GPU in there. Every single laptop you have has a GPU. Every console out, video game console out there has a GPU. FPGAs, they're for enthusiasts, really rich enthusiasts. They're high cost, high expertise, they run hot, they're definitely not plug and play. And I should know, the minority group hosts around 5,000 of these things, so.  These are really for enterprise miners. So they're relatively simple, they're plug and play, they're consumable goods, and they kind of have short lifespans and they generate a lot of heat and consume a lot of power. But the density of an ASIC lends itself really well to professional farms. So what user base do we actually want for Ethereum? Well, if Ethereum is a decentralized application blockchain, that means we kind of want as many participants and as many players as possible. Application user bases usually need to be as decentralized and distributed as possible to prevent malicious actors. And if you want an enterprise level blockchain, you also wanna make sure as many participants as possible are active to ensure your application and your code is executed on as many diverse nodes as possible. A GPU card is naturally decentralized. There's widespread adoption, it's in every device, and you have multiple manufacturers and a healthy ecosystem outside of the blockchain. Now, that point is really important. Because when you only have one line of business, you are naturally incentivized to protect it at all costs. That's an important statement. But wait, what about CPUs? Well, there's a problem with CPUs. See, they're naturally exploited for cryptocurrency mining. They're really great with botnets and you should probably trust me on that because I might have written a few back in the day. CPU implementations are also the easiest to execute on fixed function hardware because of their very single threaded nature. That lends themselves really well to fixed silicone implementations. On top of that, CPU implementations are also hard to tune for. Each architecture, shift, or each revision has some tricks of the trade to get the optimizations or in order to perfectly saturate the hardware. And of course, they're not that great at math compared to an FPGA or a GPU. They're kind of slow, not as dense.  You can pack a rack full of ASICs or GPUs. Density is really, really important to mining enthusiasts. And also remember, GPU was a GPU based algorithm from the start. That's what memory hardness means. It means that you need a GPU. We simply tuned it for GPUs. Now, a warning. This is gonna get a bit technical from this point on. This is our et hash spaghetti and logo. Lego, rather. Et hash itself is relatively simple. It requires a semi-constant scratch pad file. We call it the DAG. And then all instances reuse that same DAG for the next 100 hours. Mining et hash really just involves grabbing random slices of the data set and hashing them together. And then the DRM peak bandwidth up there, which we can see, it's easy to calculate. It's 64 iterations, each reading 128 sequential bytes. So, et hash is really just a memory hard proof of work algorithm. That means it just requires two major things. A relatively large frame buffer and as much memory bandwidth as possible. Both of these things a GPU has, great. But guess what, an ASIC can have that too. So can an FPGA. So can a PCB with just a ton of DRAM and a little compute core. Because that's all you need, memory, DRAM chips. Et hash is only tuned to memory but not the rest of the hardware. And so again, how you make an ASIC, you just remove all the other parts that are currently unused or rather all the wasted space and you get a nice increase. That's ASIC creation in a nutshell, guys. Just remove all the unwanted or wasted parts, be it silicone or compute cycles. Voila. So the inefficiencies in et hash become more obvious when you profile a graphics card with say, et minor. So this is the top picture there is taken from insight profiler. That's NVIDIA's new performance profiler, pretty sexy. Bottom one is AMD's. So you see SM up there. SM stands for streaming multiprocessor. Those are kind of the computational cores of NVIDIA GPUs, which create, manage, schedule, execute instructions from many threads in parallel.  So when we talk about a GPU ASIC, we're referring to the GPU core. As we can see, they run at less than 30% utilization right now. And on the bottom, codexl, AMD's performance profiler. We don't have as many details but you can see there, VALU busy. That stands for Vector ALUs. Vector ALUs are the digital circuits that perform arithmetic and bitwise operations for the AMD GPU cards. And it's kind of the same thing as the math core for NVIDIA GPUs. Both of these things are the building blocks of a GPU ASIC. So that means today, et hash only consumes 30%, less than 30% of a GPU core. So that's one of the major deficiencies with et hash today. And the reason you can get a large ASIC performance gain because really all it does is a small 128 byte read from the main memory. That small access size is a reason that GPUs that utilize GDDR5X or GDDR6 memory were so inefficient at executing et hash. Some of you may be familiar with our tool, et largement. It got kind of viral on the internet. Et largement abused this. So we matched access patterns of 5X and G6 memory to et hash to enable 128 byte loads to run at full speed. We have a public version of that tool for 5X. We have a private version of that tool for G6. We made a lot of money off that just because an algorithm wasn't effectively tuned to the hardware. We see up there the Titan X Pascal. It's similar to a 1080 Ti and it's pretty awful. You can see up there it has less than 20% core utilization and less than 60% memory utilization, which is on the bottom. There's also another issue, ketjack. That's the hash function at the start and end of et hash. And that can be executed much more efficiently on an FPGA or an ASIC. In fact, that's actually what the acorn line of FPGAs are designed to do. Offload ketjack computations to save system power and increase performance. You shouldn't be forced into buying extensions to your hardware just to compete with other hardware. But hey, guess what? ASICs can do that too. Profiling et hash with ketjack removed shows us that the compute cores of a card are really only utilized 20% of the time, allowing for a 10% efficiency gain right off the bat. Simly, our per source line profiling up there shows us that more than 20% of the instructions are ketjack, which can all be offloaded. That's a 30% performance gain, folks, 30%. Okay, so I've talked a little bit about the deficiencies of et hash, so what the hell did we do about it?  No, we went and kind of fixed it. So that's our prog-pow spaghetti and Lego. This was made on a plane while I was slightly drunk, so excuse the mess. There are five major changes here. See, we changed ketjack from F1600 to F800. I'll go into why that was really important in a moment. We increased the mix state. We added a random sequence of math in the main loop. We added reads from a small low-latency cache that supports random addresses, and we increased the DRAM read from 128 bytes to 256 bytes. And this is what it all became. See, the most efficient and effective algorithms are the simplest, and any ASIC designer will tell you that. Complexity leads to weakness in proof of work. Okay, so why these changes? Well, let's start with ketjack and DRAM read. Ketjack hashes used at the start and end of et hash get reduced from F1600 with a word size of 64 to F800 with a word size of 32. Why? Well, GPUs actually have 32-bit data pods, and F1600 requires twice as many instructions to execute on a graphic card. It's wasted cycles. Et hash does not use the extra data processed by F1600, so reducing this amount of data has no effect on the security of the algorithm. But what it does do is reduces any possible efficiency gains from offloading the ketjack computations from the GPU. That eliminates your ASIC speedup. That eliminates your FPGA speedup, and I should have just put that up there. Oops. So bye-bye, 30% performance gain. We leave the number of accesses to the DAG, which is also the number of the loop iterations, unchanged from et hashes 64. We don't need to touch that, don't need to dig around with it. But the DAG read size, we increase from 128 bytes to 256 bytes. This allows ProgPowl to be efficiently executed on all current and hopefully near future DRAM technologies without requiring overclocking. That means there's no more system tuning. It just works off the bat, fully tuned, fully optimized. Now, for this part, see, as I said, GPU cores are most efficient when they're doing 16 byte or forward loads. And in order to have our 256 byte loads, we have to do 256 bytes by 16 bytes per lane, which ends up with 16 lanes working together in parallel. If I'm getting too technical, let me know. When we work back from the frame buffer interface, GPUs have an L2 cache, an L1 cache, and a texture cache. We use these things for graphics and virtualization. We haven't discovered a way or a method of making use of these caches that's both efficient and portable across GPU architectures. So we leave those alone. That does allow for a potential efficiency gain in a fixed function ASIC where you could shave those off. And we'll touch in that on the breakout session. So ProgPowl doesn't target those caches, it simply passes through the DAG load. But next to the caches, we have something that I love, which is called scratchpad memory. So let me tell you a little bit about scratchpad memory. It's this high speed internal memory used for temporary storage of calculations, data, other works in progress. Think of it like your brain. NVIDIA and QtR refer to this as shared memory. And AMD and OpenCL refer to this as local memory. The defining feature of this memory, compared to DRAM, is that it's highly banked with a large crossbar. That means it allows accesses to random addresses to be processed really quickly. Something that fixed function hardware doesn't do too well with. NVIDIA's Pascal line supports a scratchpad of up to 96 kilobytes. AMD's Polaris and Vega line supports up to 64 kilobytes. And the AMD OpenCL kernel currently required additional scratchpad space in order to exchange data between lanes. So in order to effectively execute on all existing architectures and not limit our occupancy, the cached portion of the DAG, our cached bytes up there, is set to 16 kilobytes. Now the compute core of a GPU card, the ASIC itself, is really just a large number of registers that feed high throughput programmable math units. The inner loop of EdHash just uses the DAG load and then the FNV to merge the data into a small mixed state. ProgPow, however, adds a sequence of random math instructions and random cache reads that get merged into a much larger mixed state. Why is this important? The bigger the mixed state and the more random, the bigger the die size gets on fixed function hardware. Speaking of FNV, I wanted to touch on it for a moment because I did promise some folks that I would. So there's this rumor and myth going around about FPGAs with some killer performance on EdHash even when they're just bound to DDR4 memory. FNV, full or no vol, is not a secure hash function. There is a possible attack where if you know iteration I is accessing DAGX, then only a small number of next possible DAGY will be accessed. And technically, you can do a pre-calculation attack where you pre-compute DAGX with enough SRAM or BRAM followed by all combinations of DAGY and you completely skip half the memory accesses. What that means is that you violate the memory bandwidth of EdHash. Most of these FPGA rumors seem to be required 64 gigabyte, which suggests pre-computation. Combining DAGs doesn't actually work, but in case there is an FNV attack, well, there's kind of good news. See, Prog Pal doesn't have this problem.  Now, multiple people have claimed to attack this weakness in FNV to date. And who knows, maybe I might have too. So let's move on to the random math function and why that matters so much. Randomness and fixed function hardware do not mix. Random math helps to match the GPU's programmability and integer math that they normally excel at. Fixed function hardware, like I said, doesn't like randomness. FPGAs don't really like it much either. They require reprogrammability via JTAG, USB, or some other metric to employ randomness. Some people think that the random math in Prog Pal is a bit naive. They assume it's cheap to implement on ASICs because we use bit operations. Our implementation uses rotates, which require a full barrel shifter. That's pretty expensive on fixed function hardware. And sure, if the bit stream on an FPGA could be updated every 12 minutes, it could definitely implement the random math portion of Prog Pal at a lower power than GPU by creating a fixed pipeline. But there's a problem with that.  So since you're gonna need a high throughput crossbar, you know, the things GPUs naturally have, it's gonna cause a problem. And we use KISS99 for our random math. And that's kind of important for a number of geeks out there like me. We don't use Mersane Twister because it's efficiently implemented on a specialized ASIC. Actually, we don't use a lot of the random number generators out there because we need something that pasts the test U01 statistical test suite. Why? Well, test U01 actually performs checks to determine whether a random number generator produces well, truly random numbers. For some reason, most of them fail horribly. So yeah, ZOR shifts. They're not your friend, folks. They're not your friend. So by now you're getting kind of bored and you're thinking, okay, okay, great. You talked a little bit about ASICs, what are the actual results? Well, boom, baby, look at that. Look at that, almost 90% utilization in both the core and the memory. And on top of that, we can also see our scratchpad memory up there, the second screen is also completely saturated. And then look at the 580. 580 has 88.8% occupancy and saturation. Up there on NVIDIA, 88.4%. Now in et hash, we all know that NVIDIA GPUs and AMD GPUs are not equal. They're not matched. They're not balanced. PROGPAL fixes that. A proper proof-of-work algorithm is all about balance. And yeah, while our Ketchak calculation is halved, PROGPAL does add that series of KISS-99 calculations as part of our mix stage. Remember we talked about why mixing is important? Well, the film mix stage has too much data to offload to an external FPGA now. It could be implemented on a really small chip within an ASIC using a small accelerator, but that's only 7% of our compute utilization. So we see up there 91.9% of the instructions are executed within the DAG access, random math and random cache accesses, things we can't move off the GPU. Ketchak and film mix only account for about 7%. That's only a 7% speed gain. So what does that actually mean? Well, in layman's terms, it means that an ASIC for et hash looks just like this. High bandwidth memory interface, Ketchak engine, usually on an FPGA and a small compute core to do FNV loop and modulo operations. But a PROGPAL ASIC, well, it's gonna have the high bandwidth memory interface. It's gonna have a compute core with a large register file, compute core with high throughput integer math, high throughput, highly banked cache, small Ketchak and KISS99 engines. Wait, I think that's also known as a GPU. And PROGPAL is also tunable. So that's a really important feature of your proof of work algorithm. So what happens if in the future, if Dev else isn't around to keep tuning PROGPAL for the next generation of GPUs when they come out in six years? Well, any GPU architect, and there are thousands of them, can go and open up NVIDIA's Profiler or AMD's Codexl and simply tune these parameters to make sure that the GPU is completely saturated. And quite frankly, we shouldn't be on proof of work for Ethereum in six years, otherwise I'll be very disappointed. And really, that's it. That's the technical walkthrough of PROGPAL. It doesn't have to be that complex. Proof of work, like I said, it's just about matching the algorithm to the hardware just through some minor changes. And so that's it. Thank you very much. So I imagine there's gonna be tons of questions and I'm petrified. And so shoot. Great talk, thank you. I wanna play Devils advocate and challenge the premise that utilization and saturation is actually a valid metric. And the reason is that as a GPU designer, you're not looking to solely optimize energy expenditure per unit of proof of work. What you're trying to do is you're designing for gamers where performance is a key thing. And also you have constraints in terms of die area. So you wanna optimize for power. So basically what you do is that you will design your ASIC to have a reasonable trade-off between performance power and die area. But as a miner, the only thing you care about is power, well, energy spent per unit of proof of work. So you could build something that is functionally equivalent to an ASIC, but might have a larger die area or might have a higher latency, but consume let's say 10 times less energy per unit of work. And utilization would be 100%, but from your perspective, that is not a good metric. So there are three things to address there. One is a philosophical thing where we talk about what proof of work actually meant when it was originally created. Proof of work kind of means work, AKA energy expended, but that's really a philosophical debate. From a miner's standpoint, miners really care about balance. Now, progpow, it does consume more power, simply because it uses the core, which was not used before. But the important thing with that is that you take an ASIC, that also has the core, also has the memory, take a GPU, same, it will match. Your other point was that miners only care about power, but I'd really contest that. Miners really, really just care about fairness. That's the crux of it. We care about being able to all be on the same playing field and the same level of field. And then you touched on the fact that GPUs are just naturally tuned for video games, that's not true at all. See, GPUs are tuned for maths. GeForce cards and AMD's gaming line, sure it's tuned for FPS, but by modifying the firmware, you can also just tune it for math. That's the great thing about GPUs, they're tuneable and programmable and customizable. What was the other parts of your question? You can try and minimize latency, you can try and minimize area, or you can try and minimize power, or you could find a reasonable trade-off. If I was to go ahead and build an ASIC for progpow, what I would do is I would make it energy efficient first. So I would choose my cells extremely carefully so that I don't care if the 10x the latency or if the 3x the die area, all I care about because the revenue as a miner is basically going to be proportional to the amount of work that you can get done per drill burned. Only when it's compared to other miners. Yeah, of course, yeah. That's the difference. Yes, so the other miners will use GPUs and I will use something that is functionally equivalent to a GPU, but potentially has a much larger die area and runs at a much higher latency. But when you go and build a progpow ASIC, you're only going to be able to shave off, I get your question now. You're talking about the fact that you're gonna shave off all the GPU pipelines, the extra caches, all the things we've left to optimize for power. It's not about shaving off things, it's about fundamentally designing the circuit, optimize for power as opposed to optimizing. You can't really optimize for power when you just have a bunch of random math churning through there. That's gonna consume a lot of power no matter what. The only way you can get the power savings in that circuit would be to probably shave off a few transistors. So let me give you one specific example. Let's say you wanna build a 256 bit multiplier. You have two options. One is that you can build a massively parallel multiplier where basically you'll have a 256 bit by 256 array and then you'll have a massive reduction trees with lots of compressors. And that's gonna use a lot of dynamic power. The other option is to have a much smaller circuit which does less things in parallel, like much more sequential work. And that is going to consume less energy per 256 bit multiplication. Now it's possible and actually it's likely that GPU designers did not build their circuits to minimize for low power, for low energy expenditure per unit of work. I wouldn't say that. I'd go and look at the GPU's design. Again, the ones we target here are GeForce. But if you actually go and look at AMD or Nvidia's GPUs that do target low power for every energy of work, it's their new Tesla lines, specifically for G6 that consume about 55 watts per card for about, I think it's 9.6 teraflops. That's a great example of optimizing for power. It's just about which line of GPUs you're going to target. So they do build things like that. Hi. So there is a speculation that this algorithm was developed by AMD and Nvidia in order to protect GPU mining interests. So. And you did obfuscate it, people who worked, who's behind it by calling them, if they're else. Why does it matter who created it? So two parts to that. First, the amount of work and research that goes into designing an algorithm, both AMD and Nvidia have way better things to do. For a start, cryptocurrency mining, and I'm really, really, really knowledgeable on this considering I contributed to most of it, only made about $384 million last year for them, and then it made a tiny amount of money this year. And you can publicly track that because it's all in their financial reports, perks of a publicly traded company. Now, their actual revenue per month for GPUs, or per quarter, I should say, is somewhere in the five plus billion. Which is a lot. It's a lot. See, they don't care about GPU mining. They're fighting the battle in the AI space, in the TPU space, in the CPU space, and in the FPGA space. The other thing is that if AMD had designed this, they would probably have done a better job at fixing their shitty OpenCL implementation, and they wouldn't have given me so much hell in trying to get fixes. And the other thing is, again, the whole point of ProgPow is to protect at hash while it transitions to proof of stake. We do not, let me make this very clear, if Dev else does not want proof of work to exist when proof of stake is ready. The main reason for this is to make sure that proof of stake has a fighting chance in Ethereum, doesn't get destroyed by centralized entities while it's going into its transition phase. I just think that there is a conflict of interest for you to push that ProPow right now. Why? I can make an ASIC, let's be very, very public. ProgPow destroys every single optimization that I get pocket money for. This destroys athelagement. This destroys all my private optimizations. This destroys the Acorn line of FPGAs, which I think some of you are familiar with. The minority group is selling, and we do very much support. This destroys a lot of things that we very much like. I'm just curious about the statistics and security of the random math. How do you prove that it can be performed much better than FME? Because I checked this back, it's just some random mathematics calculation based on the previous calculated value, if my understanding is correct. Previous block header, not the previous value. That's a mistake. So specifically the random math function takes a few parts. It takes KISS9's random math generator. It takes the random block header that changes, random block hash, sorry. And it also changes the input, changes every 50 blocks. Now it's tweakable where you can adjust it to change every 25 blocks instead, or every five blocks if you really want to be painful. It's FNV1A that we use, not FNV itself. Like I said, it takes CDAG, which is a combination of your case, your block header, and some random math, mixes it with more random math, keeps doing that for about, I think we're doing it 64, 64 cycles, then spits it out. The code, the code is the proof. Yeah, you can go and grab the code today and you can profile it yourself, usually through Synopsys or another simulator. Again, all in the white paper, yes. Everything's completely public with that. We actually did a huge write-up on Medium that we published two days ago about this, about the security of the FNV1A function. Just to the point you made earlier. So this is purely an altruistic effort by FDFLs to transition safely to proof of stake. God, yes, I'm, core scientific loves ASICs. Please, we want ASICs to be around because they consume more power. It's better for me. And DEFINELs couldn't really care less right now. They're GPU enthusiasts. We think it's really cool. We like algorithms a lot. We like proof of work a lot. It's kind of fun. I noticed that someone on Bitcoin Talk claimed that he found a way to represent the full... Zawawa, Zawawa, yes. Full tag in several megabytes. So what that will, if he is not lying, what will that affect the prog pow? I will, again, we pointed that out. It's the FNV1A attack. It does, or FNV attack. It doesn't affect prog pow. But yes, Zawawa is onto something. And he will be a very rich man. Is there any economic analysis on how well, first of all, how the hardware that you can currently buy improves current GPUs performance versus ASIC miners and how would that change in the world of prog pow? So the biggest thing is when we do our economic analysis, we compare silicone costs to silicone costs. So I never play in the realm of what MSRP is for GPU cards because there are ways around that. I'm guessing you're talking about the cost of an ASIC versus the cost of a GPU in the world of prog pow? Yeah, well, I know so that comparing to the cost of ASIC versus the cost of GPU plus Acorn plus all the other stuff in the world. Oh yeah, so the cost of a GPU card, we'll talk roughly about that. Today, it's around $100 for the memory on its own for eight gigabytes of GDDR5, G6 is around 150. The GPU ASIC itself is around $40 or $50 depending on whether it's Nvidia or AMD. And the PCB is 25 bucks and the heat sink, admin, miscellaneous, it's around $15. Now an ASIC, an ASIC is really cheap. So we talk a little bit about the E3 because it's the one I have the most experience with. I haven't analyzed a Lindsay's at Hash ASICs but the E3 chips, the DRAM chips were brought for $3.50 each. That's actually public on, if you check there, Alpeda's filings, you can see how much was brought in that certain period. Then the PCB is only around $20 to $25. The heat sink, the sheet metal, everything else, assume $30. So there is quite a large gap and then you have to factor in the MSRP as well. Now, in a pro-pow world, they're going to actually match on a silicone and a heat sink cost. And the only savings, as I said before, you're going to get is by shaving off those unused acaches that we can't really find a use for. And that's gonna save you around $2 to $3 per GPU card. So. There's also the ASIC design costs, right? And fab and manufacturing and all that stuff, right? ASIC design, R&D, I mean, I'm not sure how public, some people's costs are, but like for a C at ASIC or for even a SHA-256 ASIC, you can get them as cheap as 10K R&D cost. And a pro-pow ASIC, it's pretty simple to make since all the code is open source and hell. Maybe when we have some spare time, we can just make open source schematics of a pro-pow ASIC.  What better way to prove our point? Thank you. Yeah, I just wanted to make a, I guess, a quick point for people in the audience from this coming from Miner. Miners mostly just care about the profit that they're making. Correct.  They have to pay their power companies in fiat, so they have to convert the crypto to fiat. So at the end of the day, they just care about their profit margin. And so, you know, if someone wants to develop a ASIC for pro-pow, and there's only a 20 or 30% speed up, just the development costs for rolling out the silicone and, you know, building all of that, which costs millions and millions of dollars, won't actually make up for the gap. So it's not like you guys have to be like just as fast as an ASIC. Even if ASICs are 10 or 20% faster, it's just not economical for them to even go out and deploy all that NRE costs to actually build it. So I don't think it's like you guys need to even make it so that there's no efficiency speed up, but it just needs to be that there's, you know, even if there's a 10 or 20% speed up, it's good enough. So, I mean. Right now, there's like a 7% to 12% speed up, but we also just like to make it so that there's no major speed up, because A, it's fun. Sure, yeah. B, fits with the chaotic theme. Sounds good. Just a follow on question for that, is that presumably, ProgPower works on standard commodity GPUs, which can be redeployed on other uses like artificial intelligence, even after Ethereum goes to proof of stake. And that's another very big factor if you're considering deploying 10s or hundreds of millions of dollars on an ASIC, which has only got one purpose, whereas a GPU farm can be reused. Is that the case? That is very much the case. I can talk a little bit about how awesome GPUs are. They're repurposable. I love that. You can play a game on it, though most miners won't be playing games with their mining farms, but you can use alternate proofs now. Golem is probably the one you're most familiar with. You can sell your GPU cycles now for rendering. So that gives mining farms a little bit more of a profitability and that contributes to a pretty cool world. Proof of useful work is something that's being explored as well. Trying to find a use case for all of these proof of work machines out there. There are some interesting things with computational fluid mechanics. There's some interesting stuff in the medical space. Nothing has been fleshed out to date simply because people haven't solved the liability problem that comes with having a very decentralized system. But Golem's on the right track, which is great. And that's taken just a year of development. Imagine what we're gonna see next year. So yeah, GPUs are pretty awesome because they're repurposable. And on that note, FPGAs are as well, but they do have a much higher skill level. You do need to go and rewrite the bit streams. You need to reconfigure them, tune them, and the amount of GPU compute architects out there significantly dwarfs the amount of VHDL and Veralog architects. Hi, great talk. I'm just wondering, you have tunable parameters. Is there integers? Yep. How about tuning which opcodes we use? I think there was like a list of 11 opcodes that we choose randomly. And maybe tuning also the hashing algorithm. Maybe something that, you know, you say that some version of Ketchak is better for some GPUs. How about some different algorithm altogether? Or maybe two different algorithms, one different one at the beginning, at the end. Just someone that's naive that says, why this, why that, poking holes, you know, at every part of your diagram. Can we do something different here? We can. The biggest thing you don't wanna do, though, is one, we wanted to make ProgPower simple today to slot into the existing at hash implementation.  It dicks around with the CPU verification as well, which we know is very, very important to the Ethereum ecosystem. And quite frankly, as long as you have enough random math in there, it's going to make it impossible to offload. We could replace Ketchak with another hash function. I haven't really thought too much about it. We also had a really cool idea of merge mining as well, which would be a great way where, you know, other proof of work algorithms could use ProgPower in tandem to compute their final cycles to get a bit more ASIC resistance. That would actually defeat the nice hash problem that we all have in mining. But that's a lot of development work as well. And just to be clear, these tunable parameters are just for future revisions of GPUs. So to date, all of these are completely tuned for NVIDIA's latest line of GPUs, which is the RTX 2000, AMD's latest line, which is their Vega version three, I guess they're on now. And also we did have an Intel GPU sample, but I don't think that those will be massively used by miners unless you're very, very rich. So great talk. Thank you. Even though I think I probably only get 10% of it. I wonder from integration standpoint, how feasible, how far along are we? Because I remember seeing that the time to verify the proof of work increased by a margin that might make it infeasible to actually use it. Yeah, so let's make that very public. That is simply because of my terrible Go skills. We are really great on the GPU side, not so great on standard client code. We fixed that with an optimized implementation, had some great help from Parity devs, from Fminar developers, from the whole Ethereum community really. There is going to be, it's gonna take two times as longer to do a verification, simply because two times the data is consumed. That's the 128 bytes increased to 256 bytes. But as long as everyone's verifying proof of work the same, it evens out and it levels out. And a 2x slowdown is much more palatable than what it originally was, which was a 9x slowdown. So that's what happens when you don't optimize your code, guys. Hello, me again. On the legal front, someone might say some things are copyrighted, some code is sort of intellectual property and other people are running this code. Would there be any barrier? Does someone own this intellectual property? Does anyone own the copyrights to Progpow? Would there be someone that could later on say, okay, you're using my code, you're running it now? I mean, it's open source, so if you wanna go patent the open source code licensed under the MIT license, go for it, guys. No, there's no copyright. Again, this has been public, fully public, fully open source since, I think we released it in April. Oh, God, it's GPL infected. Well, there we go. There we go. I have several questions regarding the specs. Are there official specs now? Yes, there are. In the beginning it was a bit janky. Yes, I know. I realized that there is still some use of FNV in Progpow. FNV1A, I get it. No, the normal one. Oh, yeah, yeah. Because I've seen the primes used by the normal one. Why is that? Simply because we didn't wanna mess around with the original proof of algorithm too much because it affects the balance of the compute core of the GPU. If... Is it in the deck generation? Yes, it is. Oh, okay. It is. Again, if we go back to the original... Then the question is if we shouldn't just change this, if we change Progpow, we should maybe just change this if this guy from the... We can, we can definitely take FNV out altogether. We'd need to find another really light verification fast hash that would just require some sort of research. Maybe we should just change it to FNV1A. Yeah, we can do that. Maybe, yeah, okay. Slice it all out. Then the cache, the small cache in the shared memory. Why is it filled that way? It's filled like the first 128 bytes from the deck or something or the first elements from the deck. Why that? Why not some randomness or something? Simply because that would... So if you were going to make a Progpow ASIC because it doesn't saturate all of it completely, in theory, in theory, you could go and create a sort of a compute core that takes all this randomness and does a pre-compute with an FPGA. It would only have to do it every 12 minutes. You could have a very dedicated bit stream developer. And you wouldn't always get that balance between this is the important part. You wouldn't get the balance between an NVIDIA GPU and an AMD GPU. Sometimes, if there was too much randomness, you'd end up going way over the cache availability for an AMD GPU. The AMD GPU here is the big bottleneck. I think both architectures have to save the same amount of data. Correct. But if you have the randomness changing the bytes, that screws with the saturation. And then that would cause the AMD GPUs to underperform. We did try that early on. It didn't work out too well. Then the update. So we have an update every 50 or 60 blocks. Yeah, we put it at 50 blocks. I think we finalized on 50 blocks. You could change it to 25 blocks, but there's really no point. 50 blocks is pretty good, but I guess if you wanna be super hardcore, change it to 25 blocks. What's the overhead of this update? Do you have some? What do you mean by overhead? Like, do you have to pre-comput the kernel that runs? We do. On a GPU, it's really fast. We publish it publicly. It should be like 0.2 or 0.3 seconds. 25 blocks gets a little painful. On an FPGA, you're still gonna have to go and re-push out the bit stream every few blocks, which will be painful. That will be a three to seven minute overhead. Do you know how much CPU that computing the kernel costs? I don't actually. I should measure that. I know that some of the mining rigs are running on almost full capacity on this really small Intel cores. Most of them have a Core 2 Duo, which should be okay with it, quite frankly. And all of our computation as well takes place on the GPU. And we can actually make sure that the CPU is just doing a very slight amount of verification. So we could actually tune that. That's more of a, that's not on the proof of work side though. That's more in the application or like the client side. So definitely we need to work with the Ethereum developers for that. Again, the clients are not our strong suite as is proven by the CPU verification. Will you update the EIP to have the new spec? Yes, that has been on my list of things to do. I did get the medium article out. I did update the GitHub, but yes, I need to update the EIP. Will you develop some test cases for other clients to use? Yes, I need help with those, quite frankly. We couldn't, I think we could... That would be amazing. I do not have enough spare cycles to date to be able to do all of these things. Okay, thank you. We have about five minutes left. Could you speak a little more about whether this changes the bandwidth consumption on the bus, on the GPU because of the increased cache size? Yeah, that's the whole point. It actually does change the bandwidth consumption. Again, generically, it's only 60% consumed, which is a problem. We do 90%. You can never get 100% bandwidth consumption in real world applications. It's just, it's impossible. It's one of the things GPU architects struggle with. So that's the best we're able to do to date. In theory, you could... I'm sure there's like a trick, and I'll go noodle on this because if PROGPAL does get adopted, naturally I'll wanna go and break it again. I'm sure there's a 1% speedup you could get with some clever tricks on the minor side. But other than that, yes, it changes your bandwidth consumption, consumes 90% of the bandwidth. That's basically what we mean by bandwidth utilization. It's how much bandwidth is consumed. Hi, I'm still thinking about how to break your scheme. That's okay, man. That's okay. I wish, I wish DEF and elsewhere here, even if they were wearing masks, they'd love you.  Let's assume you get it to 100%. You're still not using the full flexibility of the GPU. So for example... Well, why? You're not using the full flexibility of the GPU. So for example, there will be a circuit that does addition and then a circuit that does multiplication, and then you call them one after the other. And the reason why these two circuits would be separated in a GPU is so that you can mix and match. But because you're calling them in a specific order, as an ASIC designer, what I could do is I could build a clever circuit that does A and B at the same time and uses less energy than would be if you first use the A circuit and then the B circuit. Yes. Actually, that was something I was gonna put in my slides. We use a... Again, I mentioned we use a barrel rotate shift. Our implementation of rotate is more... GPU implementations, I should say. It's more efficient than any existing ASIC to date. And any existing fixed function hardware. Again, GPUs are... I think most people forget, GPUs are really just ASICs for math. That is what a GPU is. So what you're specifically referring to is a barrel shift rotator, and the GPU to date is the most efficient implementation of it. That's why when I say that, if we wanna go and make a prog-pow ASIC, it just ends up mimicking a GPU because you just mimic that. I'd love to touch more with you after this on that, actually, because I have a write-up on that, because we got that question asked a lot from an FPGA developer who was talking about putting in square roots and other things into prog-pow. So I'm done.


Well friends, today we shall be discussing IC engine series fuels supply systems in CI engines and in that we shall be discussing on the topic fuel injectors. Let me introduce myself first. I am Dr. Prakash Sauronke, working as associate professor in department of mechanical engine. At the end of this session students will be able to describe working of different types of fuel injectors, fuel injector. In IC engine, in CI engine, in a type of IC engine, compression ignition fuel is injected at the end of compression stroke at high pressure through a component which is known as fuel injector. There are mainly three types of fuel injectors. One is blast injector, mechanically operated injector, automatic injector. So blast injector as used in air injection system where air blast will help the fuel to go inside. Atomical engines are mainly fitted with automatic injectors. So because it is not possible to use mechanically operated injectors there, so automatic injector. Now, atomical fuel injectors which are automatic, fuel injectors atomizes that fuel into very fine droplets. Now you tell me why we need to atomize the fuel. Why to atomize? We have seen atomize means breaking into very fine light, fine droplets. But why we need atomization increases the surface area of the fuel droplets. Because very fine droplets are there so it will increase the surface area resulting in better mixing and subsequent combustion, better mixing with air. Better mixing with air and then subsequent combustion so that is necessary. Atomization is done by forcing the fuel through a small orifice under high pressure, small orifice, small hole and under high pressure. The injector assembly that you need consists of different parts, a nozzle valve, a compression spring and an injector body. A cross sectional view of a typical Bosch fuel injector is shown in figure. We shall be seeing the figure. The fuel supplied by the injection pump exerts the force against the spring to lift the nozzle valve. So we shall see the figure and then we will again come here for discussion. So this is how that fuel injector is constructed. So this is nozzle body. This is nozzle valve. So this is the valve. This is the fuel. So that is coming and this nozzle valve is opening here. So there is a hole here but it is right now closed. So this is normally closed type. So fuel will be coming here so that will go here and it will lift this particular nozzle valve. Now this is nozzle cap. Then this is spindle. This is spindle. So this is the fuel supply passage. So this is the leak off. This is the spring and here there is a lock nut. Here there is adjustable screw and here there is a cap. So these are the different parts. Now let us see the working. The fuel supply coming from the pump at high pressure will come here and enter here below this portion of the nozzle. So when say pressure is here so this will lift the nozzle valve against the spring force. Normally the spring will pressurize here through this spindle and this will be normally closed. But when the pressure is higher fuel pressure so this will lift and this will open the passage and then fuel will be injected inside the combustion chamber or inside the engine cylinder. Now the fuel supplied by the injection pump exerts force against the spring to lift the nozzle valve that we have seen just now. Fuel is spread into the combustion chamber in a finely atomized particles because of high pressure and very small opening so that hole which is drilled with very small depth. When fuel from the delivery pump is exhausted the spring pressure pushes the nozzle valve back on its seat. So when the fuel is exhausted the pressure will drop down and when the fuel pressure drops down the spring will push the nozzle valve back to its seat and it will again close the opening. The spring tension and hence the valve opening pressure is controlled by the adjusting screw provided at the top. So we have seen at the top there is a screw if we want to see the figure again so here yes. So this is the adjustable screw and nut okay. So which help us to control the opening pressure as well as spring tension. For lubrication between nozzle valve and its guide some quantity of fuel is allowed to leak through the clearance between them. So there will be slight clearance between the nozzle valve and its guide so that some amount of fuel is leaked so that will I mean cause the lubrication and that will be throwing back to the I mean fuel supply system. So here we have seen that Lycop so Lycop is provided here through which the fuel will return. So this fuel is then drained back to fuel tank through Lycop connection. Nozzle is that part of the injector through which the liquid fuel is spread inside the combustion chamber. The nozzle should perform the following functions so what are the functions expected from the nozzle so that we shall discuss. One is atomization it is required for obtaining proper mixing of the fuel and air in the combustion chamber that we have studied earlier also. Then distribution of fuel so that is one more important function. Distribution of fuel to the different areas within the combustion chamber so that is one more I mean important function so that is expected of the nozzle. Then factors affecting these two are injection pressure. Higher the injection pressure better is the dispersion and penetration of the fuel into the different location in combustion chamber that is natural. So penetration means depth up to which the fuel will be penetrated. Then another factor which affects is density of air in the cylinder. If the density of compressed air in the combustion chamber is high then the resistance to the movement of the droplets is higher and dispersion is better. So resistance to the movement so that will be higher so that will cause the better dispersion. Then apart from that physical properties of the fuel the properties like self-ignition temperature, vapor pressure, viscosity, etc play important role in the distribution. If self-ignition temperature is low vaporization will be earlier vapor pressure will be more. Viscosity is small then distribution will be better. I mean more then distribution will be lesser so all these are the other properties. Apart from that there is one more requirement of the semi nozzle. So that is prevention of the fuel I mean impingement on the walls. There is possibility that fuel may impinge directly on the walls of the combustion chamber or piston. So instead of going in the combustion chamber it will go directly to the walls or I mean combustion chamber as well as the piston top. So this fuel striking the walls decomposes and produces carbon deposits. So since it will be directly going on the walls it will not come I mean combined with the oxygen or air so it will not burn and that will decompose due to high temperature and produce carbon deposits. So it causes smoky exhaust as well as increase in fuel consumption. So smoky exhaust is there because so that that carbon deposits they will enter say the products of combustion and say that will cause incomplete combustion and it will also increase the fuel consumption that is unutilized fuel. So this is say one more drawback another function say that is known as mixing. Mixing the fuel and air especially in case of non-turbulant type of combustion chamber should be ensured by nozzle. So there are normally turbulent type of combustion chamber and non-turbulant so we shall be discussing them later. So in turbulent chambers the turbulence helps for I mean better mixing however in case of non-turbulant since there is no turbulence or movement of the air so mixing function is again the important aspect or important requirement of the semi nozzle. Again discussion from this we are taken from the book of Mathur and Sharma Dhanpatrai Publications. Similarly internal combustion engine book by V. Ganesan's McGraw Hill Publication of India. I thank to them and I also thank you for patient listening.


An ethical pragmatist might tell you that it's probably not a good idea to steal a lady's purse. Why? Well, it's just not likely to go well for you. Okay, let's start in the middle of things because that's where everyone starts. Kicking a dog for fun is wrong. Being there for a friend when they need you is good. You have a duty to get a ride home if you've been drinking heavily instead of trying to When we see injustice or integrity or honor or cruelty, there's some moral aspect of that experience, something that is often as apparent to us as color or size. This thing is red, that thing is huge, these things are wrong, those things are good. But that moral quality of our experience doesn't have any sort of physical manifestation outside of our heads, and we sometimes disagree about the moral character of certain phenomena with no clear way to resolve that dispute. One person might see drinking alcohol as a terrible moral transgression, while someone else might see it as harmless fun, or maybe even a sacred duty. We have to ask, what the hell is going on here? There are a handful of ways people have tried to figure that out. Some philosophers analyze these experiences to try and find some underlying set of rules, an ethical rubric or algorithm that we can use to explain what's right and wrong and why, invariably running into wacky counterintuitive notions about good behavior. Others take the weirdness of the whole situation as proof that morality is nothing more than a shared human fantasy or delusion, maybe a whimsical foible of culture and evolution, which, well, maybe, but what then? What are we supposed to do with moral dilemmas and the moral aspects of our lives? Ignore them? Pick and choose what to do based on some other arbitrary criteria? And then there's the pragmatists. You may remember pragmatism from earlier episodes as a non-standard attitude towards truth. Most of the time, we talk about things being true or false as a function of correspondence. The world is like this, we believe that, if this is the same as that, if our beliefs match up to how the world is, then they're true. But pragmatists take a page from evolution and a page from science and use them to define truth a little differently. For pragmatists, the idea that humans could ever know capital T truth is overselling it. I believe that the sun will rise tomorrow, and as far as I can tell, that belief is warranted. But if the sun didn't rise tomorrow, I wouldn't stamp my foot angrily and tell the universe to pull itself together because the sun will rise tomorrow is the capital T truth. My beliefs were wrong, they were false, and the only way that I know about it is because they stopped working.  For pragmatists, there's no higher standard of knowledge to be aspired to than a heuristic or rule of thumb that has survived repeated testing so far. We keep the ideas that have worked for us and discard the ones that don't. We can't ever know if we've gotten anywhere close to the capital T truth, we could be standing directly on top of it and still not see it. But by throwing models that fail in the garbage, we can narrow and incrementally improve the fitness of available ideas over time, maybe ratcheting ourselves closer to what's actually going on. The pragmatist account of morality squints sideways at this whole mess with ethical systems and error theory and moral experience and asks, okay, what's useful here? The various philosophical accounts of ethics and whatnot can be helpful in highlighting some of the important features of morality, informing the models we built, but trying to figure out if moral facts really actually exist or which account of ethics is capital T true are both missing the point. The thing that's of paramount importance, what we're actually trying to do, is getting satisfactory outcomes, cultivating a model of morality that allows us to reliably succeed in our moral endeavors. That can mean lots of different things, but it cuts a neat middle path between these factions in the land of correspondence theory, rather than taking a hard line that such and such algorithm is the truth about morality, or that the only truth is that anything goes, or that the truth is that morals don't exist. Pragmatism takes a step back and says, look, I'm not really interested in whatever you think the truth is or isn't. Why don't you just tell me what works? Better yet, why don't you tell me what doesn't work? This emphasis on the importance of practice in model selection has an interesting effect on the scale at which pragmatists analyze different moral theories. As I said at the beginning, we only engage with this question of why morality is weird and how it works in the middle of things. Long before we're in a position to think about the subject in any rigorous fashion, we grow up living and thinking with numerous moral ideas and practices already in place, shaping what and how we think and act. It doesn't even cross your mind that you might have some ethical obligation to wear teal or hop in one foot right now. That's not how morals even work, right? The way that you think about those actions as lacking any significant moral character might be different if you were raised with certain notions about teal or hopping, but for some reason, for you, that's never been the thing. In that sense, when we reflect on what sorts of moral codes or theories or systems we ought to adopt to get satisfactory moral outcomes, it's not like we're starting from scratch. We're trying to evaluate and maybe slowly modify our existing moral habits, patterns of behavior and thought and environment that feed on and inform each other. Like, imagine someone who lives out in the countryside and doesn't really keep up with news, who's totally ignorant of the COVID pandemic. Her habitual behavior is to go out in public without a mask on, and for a long while, that's worked for her. She hasn't run into any moral consequences of that behavior that might be considered unsatisfactory. However, when she goes into town for her semi-monthly shopping, that habit suddenly experiences some problems. Everyone is wearing masks and she isn't. The store won't let her in without a mask on. People are scowling at her. Hopefully, before she gets to a point that her maskless habit reaps some really bad consequences, either for her or for people around her. Her intent, her behavior, or her environment can shift into a pattern that works better. Maybe she reads a sign about COVID and decides to mask up to be socially responsible. Maybe she puts a mask on just to stop people from glaring at her without really understanding why. Maybe the grocery store has a checkpoint where they give her a free mask for entry. It's unreasonable to expect her habits to change unprompted, like she should just somehow know to make a mask for herself before she leaves home to avoid negative moral consequences. But as soon as they stop working, a good pragmatist would say that they need to adapt. Adapt is a key term here. Remember when I said that pragmatist ethics takes a page from evolution? Pragmatists take a page from evolution. Okay, yeah, I did say that. If you've studied evolution, you might know the constant struggle of trying to crowbar apart adaptation from intent. Like, someone says, birds evolved wings so they could fly, and every biologist and geneticist in the room goes, not really? There's this process at work where creatures mutate and some of them die off and other ones replicate and their offspring have some of the same traits and traits that are advantageous for survival in their environment accumulate slowly over time, but there's no real desire or design in that process. These features of birds that happen to be good for flying are just genes doing what they always do, slowly changing to facilitate replication in their surroundings. One might see the same sort of process at work with the moral norms and habits that we find ourselves in the middle of. Ethicists might say that they have some overarching purpose or goal, like minimizing suffering or realizing God's will. Error theorists might argue that they're just random noise with nothing to recommend one moral assertion over any other. Pragmatists, again, find an interesting middle road of good adaptation. There are certainly moral theories that work better or worse than others in certain contexts, so there's definitely some sort of normative standard at work, but that doesn't imply that there's any one ethic to rule them all, any more than there's one optimal bird wing. It's not anything goes, but it's not an uncompromising monolith either. As per the Last Thunk episode, this view gives us some motivation to not simply fling all our moral intuitions and habits into the garbage, just because we noticed some weirdness, inconsistencies, or places that they don't work. The cultural notions about right and wrong we were raised with obviously aren't going to give us unerringly successful moral outcomes in all situations, but they are probably well adapted to our environment in some helpful ways, granting us some useful heuristics for navigating certain common moral situations. Philosophers and game theorists have devised all sorts of post hoc justifications for why breaking promises is generally wrong, or why saving more lives is generally good, all sorts of benefits that people who just follow their cultural norms of morality get without a second thought. This certainly doesn't mean that we shouldn't reflect on those, or revise the places that these norms fail less, or come into conflict, but so long as they seem to be working, maybe some charity is warranted. There are obviously some important details missing from this very small summary of the pragmatist account of morality, like what it means exactly for a theory to work, how you can be sure if it's stopped working, who's making those decisions, all sorts of annoying persnickety details upon which the ultimate viability of the whole enterprise turns. But for me, it's kind of refreshing to examine the moral aspects of my experience without trying to invoke some first principles account of expected utility, or bite bullets about moral error theory, or any of that, to just look at my moral universe, see what I'm doing, what's working for me, what the world is like, and what I want to be better. At least, that's what's working for me right now. What about you? Please leave a comment below and let me know what you think. Thank you very much for watching. Don't forget to change this thing. Ah, damn it. Yep, it's me. Future Josh, just a reminder for anyone watching this, Episode 200 is coming up. I'm going to be rewatching some old episodes to comment on them. If you want me to sit through one in particular, be sure to visit the link that's in the description and vote for your favorites. All these favorites.


I'm Major Randall Hobbs and I'm a personal injury attorney with Rainwater Holt and Sexton in Little Rock, Arkansas. So being a lawyer does require great dedication. There's continued education that's required upon completion of law school so you're continuously learning and trying to stay abreast of the latest legal issues and decisions that the court is making along with any kind of changes that the legislature has made. So it's a constantly learning and evolving process. In the Arkansas Army National Guard, I'm a member of the 77th Combat Aviation Brigade where I serve as an Operations Officer and have the additional duty as flying as a pilot in command. So practicing law full-time and balancing that with my duties as a pilot in command in the Black Hawk is very demanding. In order for me to be successful at either career requires the cooperation of both my law firm and the Arkansas Army National Guard, I've been very fortunate that both organization supports the other and encourages me in both my jobs. What keeps me in the Guard today is the sense of service to my community. I stayed in the Guard originally as a sense of duty and responsibility and over the years the Guard became a family to me and it's that family that I look forward to seeing every drill we can. The level of fun that I have when I have the opportunity to go fly Black Hawk for the Arkansas Army National Guard is something that I can explain. I look forward to that each and every week when I go out there to do that. I am Major Randall Hobbs and I am being my best.


Would you please join me in welcoming to the stage, Tan Sri Dr. Zeti Akhtar Aziz. First of all, welcome to this year's Leadership Energy Summit, organized by our leadership and governance center. And the focus on leadership energy reflects its importance, as it's been highlighted in today's leadership. The contemporary environment that we are living in has become increasingly more challenging. It's characterized now by highly destabilizing and tumultuous events. Not only are we living in a world that has become highly unpredictable and unstable, but in a world that is frequently being subject to extreme conditions and all of us are tested to the limit. How do we survive then against the odds manifested in this environment? It is all about the ability to endure and prevail. It's all about being able to succeed and thrive in such an environment. It is all about becoming resilient. I've always talked about a resilient economy and a resilient financial system, but it's all about being resilient, yourself being resilient. Resilience is a key to surviving in this environment. Well, as you know, of course Rajiv has got us to a great start in telling us about what leadership means and leadership energy, its sources. And today we are going to be privileged to hear and be inspired from the experience of personalities who have not only survived against such great odds, but who have also succeeded immensely. Let me take this opportunity to express our gratitude to our distinguished speakers that have come from different parts of the world to share their knowledge and experience on this subject. It is all about their perseverance and resilience and how they have defied all expectations. And the issue before us is the source of their energy to persevere and their courage to stay the course when it appears to be immensely hopeless. In the business of central banking, we are increasingly being confronted by these extreme conditions and such resilience is therefore key. I have described central banking, the business that I have been in for 35 years as being an unfinished business. It's an unfinished business because there are always new challenges on the horizon, endless demands emerging from an ever-changing and more complex environment and great expectations that central bankers will provide all the solutions and take the necessary action to resolve the financial and economic problems that confront us. The central bank is also at the forefront in the management of financial and economic crisis, a phenomenon that has plagued the world with increasing frequency. And we all know that such crisis affects everyone in the country and all businesses. The central bank can also be described as a high-impact organisation. Its decisions or indecisions, its action or inaction will have major and far-reaching implications and consequences on the economic well-being of the public at large and the entire spectrum of businesses. The responsibility and accountability is therefore immense. It is all about bringing value and benefits to the citizens and it's all about making the difference, the difference that Rajiv talked about. In an environment of greater transparency and enhanced communication, there's greater awareness of the prevailing circumstances. This has produced higher expectations for the delivery of results. Energy is therefore derived from this sense of purpose and meaning of what is of great value to you. Fiercely knowing this responsibility and accountability is the very source of the drive and intense energy to succeed. Knowing the high costs that destabilising developments can have on the people and to businesses and the potential damage to the nation is a major prompt of the perseverance to press on to survive and to succeed. Despite extreme conditions and in the face of the threat of being thrown off balance, confronting the realities and the need to produce a solution when it seems very hopeless, provide the courage to stay the course. Knowing also that the stakes are high and knowing that sometimes you are the pillar of hope that spurs the unwavering determination. From my experience as a lifelong career central banker, such extreme conditions that test us have become increasingly frequent. No longer are we in stable conditions where we can predict by projections looking at the past and projecting into the future. While there have been many successes that have been achieved, there have also been those moments that have been most trying and devastating. During such times, developments set you back to a much worse situation than your original position. Those times have arisen from external shocks that are beyond your control. Sometimes it's also from ambitious agendas that you want to achieve to create the difference, to make the difference for a better future. And sometimes you have violent resistance and sometimes you have domestic stress that are brought on by actions that are in conflict with the central bank's mandates or from political tensions. We've seen this time and again. The ability to endure, to persevere, to be resilient in the face of such extreme odds is about having a great sense of purpose of what needs to be achieved and the motivation, knowing what the motivation is of why it needs to be achieved. The sheer responsibility and awareness of the accountability that comes with it is the very driver of such perseverance. It is also the fear of failure and knowing the far-reaching and damaging consequences of such failure. This is reinforced with the values and discipline to stay the course and this is truly important in central banking as well as in businesses to do what is right and what is in the interests of the people. The discipline is important so that the central bank is consistent in its behavior, in managing the challenges and conditions or even in the aspirations to push the frontier and to create greater value to the people and for the country. During such times, having clarity in the vision and on the objective of what is to be achieved becomes paramount. This has to be the starting point if it's to draw on the energies of the entire organization. Articulating it with great clarity throughout the organization allows the collective alignment to the goals. No longer are we working in silos which was the case before. We had to change. This also avoids being diverted having that clarity. It avoids being diverted by distractions and what we refer to as noise when indeed we are confronted with unstable and destabilizing times. We are pulled in different directions. It is also imperative that when we are ambitious with bringing about change and transformation, knowing clearly the outcomes and the benefits it brings increases the potential for bringing diverse groups within the country and across countries towards achieving this common goal. This is what I found immensely important to recognize when we are dealing with a region where we want to become more cohesive or amongst emerging economies or amongst different regions where we have an agenda to promote because of diverse backgrounds diverse thinking and diverse agendas or objectives. This has become very, very challenging. There's one aspect that Rajiv hasn't mentioned but I would like to mention because I think it has an important role and that is about being paranoid.  This is sometimes referred to as productive paranoia. I always knew it from the beginning and my staff always thought that it was being paranoid but I do believe that as we enter into an environment where we do more and more risk management what is risk management? It is about assuming that the worst can happen and you want to prepare yourself for it. Central bankers need to excel as risk managers knowing what could go wrong and preparing for the worst that is yet to come. It involves building the buffers to prepare for the unexpected events before they happen. When I ask a question, for example, about how are we going to manage the lift-off and for those of you who are not economists or financial expert, they are referring to the Federal Reserve Bank and when it will lift off from being maintaining interest rates at the near-zero level after seven years of maintaining it at that level. This is called the normalisation of interest rates and my response is it is not what we will do now but what we have done before it happens that will see us through this period. It is not only the buffers that we have built but the capability that has been developed to allow us to better intermediate and absorb such a shock and to allow us to withstand the volatile financial flows that are already occurring in anticipation of this eventuality. Sometimes there's also what is called black swan events and as we all know, black swans are very rare so this is something that really happens and these are defined as those developments that have a low probability of happening and a development that is very difficult to predict and anticipate. Like the lift-off, we all know that that's an eventuality that's going to happen and therefore we prepare for it but in this particular case sometimes something happens suddenly that is very unexpected. Therefore, being paranoid and building the resilience against such shocks will contain its damaging effects. Therefore, continuous rigor needs to be applied at all the time during the good times and during the challenging times. Vigilance, detecting developments that could signal danger, early recognition of risks are all important also knowing how your risk profile changes will avoid being taken by surprise. Central banking is also not for the faint heart. It is not only demands the high level of energy not just the physical energy but all the other energies that Rajiv talked about but the emotional, spiritual and I have it here and the mind. When tested to the limit it's from these sources of energy that the strength is derived investing in these sources of energy will avoid its depletion. Energy should not be taken for granted then there's also courage. Energy derived from your convictions and values that you uphold reinforced by your sense of purpose and what motivates you. Finally, I want to re-mention something that I mentioned a year ago at the 2014 summit. I spoke of the ability to generate and ride on the positive cycle of leadership energy mobilizing energies in an organization to be aligned to achieving an outcome it also generates second round of energy burst from others in the organization and the continuous positive energy loop provides continuous motivation and momentum that can drive the organization. It is mutually reinforcing phenomenon that I have experienced in the bank time and again like when your staff are demoralized and your team is demoralized you drive the strength and the aspirations but when you are down the organization feeds the energy levels for you as well and I do believe that this is an important phenomenon in an organization that you are not alone. Let me conclude my remarks. The demand for leadership is immense and in the current international and domestic environment it requires tremendous leadership energy that energy that is also sustainable. This leadership energy summit we will in this leadership energy summit will bring the experience of successful individuals on the source of their energy in generating the outcomes and results that have made a difference. We will also learn about other sources of energy from which we can tap on and strengthen. This is the challenge of the new generation of leaders if they will truly be able to make lasting and meaningful changes in our environment. Please note let me wish you a highly energized summit. Thank you.