I was tasked to create ethereum smart contracts in my previous job.

the library most recommended by other developers to create smart contracts was hardhat.

to create and debug the smart contracts, I developed them using test-driven-development methods. The tests gave me a way to print out and inspect variables.

just as I was done with the development I read somewhere that hardhat has a console.log() utility. You import it with import hardhat/console.sol and use it like JS’s console.log. I wondered how it worked. Upon testing, it seemed to only allow a maximum amount of parameters.

so i decided to look at hardhat’s internals and find out how they do it.

the first step was to find the console.log() utility function.

this is their repository https://github.com/NomicFoundation/hardhat

$ ls 
config  CONTRIBUTING.md  crates  docs  LICENSE  package.json  packages  README.md  scripts  yarn.lock

im not familliar with their file structure conventions. But I can guess that the source code is not in config/, docs/, or scipts/.

$ ls crates packages
crates:
rethnet_evm_napi

packages:
common                 hardhat-core       hardhat-foundry          hardhat-solhint  hardhat-truffle4  hardhat-waffle
eslint-plugin          hardhat-ethers     hardhat-network-helpers  hardhat-solpp    hardhat-truffle5  hardhat-web3
hardhat-chai-matchers  hardhat-etherscan  hardhat-shorthand        hardhat-toolbox  hardhat-vyper     hardhat-web3-legacy

i didn’t know what crates/ were so I also tried it. anyway, packages/ contains hardhat-core/. Inside it we’ll find console.sol.

let’s see the code.

$ cat packages/hardhat-core/console.log

link to it: https://github.com/NomicFoundation/hardhat/blob/main/packages/hardhat-core/console.sol

opening it, we find 1513 lines of repetitive, possibly auto-generated code.

here’s an interesting part of the code:

$ cat packages/hardhat-core/console.sol  -n | tail -n 30
1503
1504          function log(address p0, address p1, bool p2, string memory p3) internal view {
1505                  _sendLogPayload(abi.encodeWithSignature("log(address,address,bool,string)", p0, p1, p2, p3));
1506          }
1507
1508          function log(address p0, address p1, bool p2, bool p3) internal view {
1509                  _sendLogPayload(abi.encodeWithSignature("log(address,address,bool,bool)", p0, p1, p2, p3));
1510          }
1511
1512          function log(address p0, address p1, bool p2, address p3) internal view {
1513                  _sendLogPayload(abi.encodeWithSignature("log(address,address,bool,address)", p0, p1, p2, p3));
1514          }
1515
1516          function log(address p0, address p1, address p2, uint256 p3) internal view {
1517                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,uint256)", p0, p1, p2, p3));
1518          }
1519
1520          function log(address p0, address p1, address p2, string memory p3) internal view {
1521                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,string)", p0, p1, p2, p3));
1522          }
1523
1524          function log(address p0, address p1, address p2, bool p3) internal view {
1525                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,bool)", p0, p1, p2, p3));
1526          }
1527
1528          function log(address p0, address p1, address p2, address p3) internal view {
1529                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,address)", p0, p1, p2, p3));
1530          }
1531
1532  }

this looks fascinating to me. I’m less familiar with statically-typed languages, so I don’t know how common this method is. I’ll explain why it intrigues me.

most of the file consist of functions with the name log. In python or probably any dynamically-typed languages, this would not work. For example, if log() is called, The interpreter would not know which log, to use out of the many logs defined.

1524          function log(address p0, address p1, address p2, bool p3) internal view {
1525                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,bool)", p0, p1, p2, p3));
1526          }
1527
1528          function log(address p0, address p1, address p2, address p3) internal view {
1529                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,address)", p0, p1, p2, p3));
1530          }

in solidity, this is a completely valid use case. Although the function names are the same, the compiler can determine which log to use by looking at the data types of the arguments, and finding which log function has the correct parameter data types.

1524          function log(address p0, address p1, address p2, bool p3) internal view {
1528          function log(address p0, address p1, address p2, address p3) internal view {

For example, these two function definitions are almost the same, except the fourth parmeter. Line 1524 handles log calls with specifically 4 parameters with respective types: address, address , address, and bool.

Whereas Line 1528 handles log calls that pass exactly 4 address data types.

1524          function log(address p0, address p1, address p2, bool p3) internal view {
1525                  _sendLogPayload(abi.encodeWithSignature("log(address,address,address,bool)", p0, p1, p2, p3));
1526          }

This design means that only a fixed number of arguments can be accepted by hardhat’s console.log. Console.log will not work if it’s supplied with arguments that are not pre-defined in console.sol.

I later found the script that generates this code. It’s in hardhat/packages/hardhat-core/scripts/console-library-generator.js.

The parameters p0 to p3, are passed to abi.encodeWithSignature which is then passed to _sendLogPayload.

$ cat packages/hardhat-core/console.log -n | head -n 14
 1  // SPDX-License-Identifier: MIT
 2  pragma solidity >= 0.4.22 <0.9.0;
 3
 4  library console {
 5          address constant CONSOLE_ADDRESS = address(0x000000000000000000636F6e736F6c652e6c6f67);
 6
 7          function _sendLogPayload(bytes memory payload) private view {
 8                  uint256 payloadLength = payload.length;
 9                  address consoleAddress = CONSOLE_ADDRESS;
10                  assembly {
11                          let payloadStart := add(payload, 32)
12                          let r := staticcall(gas(), consoleAddress, payloadStart, payloadLength, 0, 0)
13                  }
14          }

At first glance, I can deduce that Hardhat sends the messages from console.log to a dedicated public address. It then scans the address for messages and outputs any messages that are sent to it to the terminal.

So that’s Hardhat’s console.log. We looked at its internals and found mysterious code that turned out to be a smart solution to the problem.