search

marmarachain / marmara

This is the main repository for Marmara Credit Loops Smartchain containing the open source CC Files.
https://marmara.io/
Other
18 stars 8 forks source link

S8 NN Update preparations #47

Closed rumeysayilmaz closed 1 week ago

rumeysayilmaz commented 1 week ago

This PR includes the changes for s8 NN update. We kindly request @DeckerSU and @dimxy to review the changes. Thank you in advance.

Regarding the changes

dimxy commented 1 week ago

changing the default indexes (enabling addressindex and spendindex by default) will likely cause all nodes to resync or reindex after the update

addressindex and spendindex as true are critical for marmara to work: some cc functions require them. Those settings are enabled from the chain start

DeckerSU commented 1 week ago

addressindex and spendindex as true are critical for marmara to work: some cc functions require them. Those settings are enabled from the chain start

You're absolutely right—I just mixed up the launch parameters with another chain. In this case, -addressindex=1 -spentindex=1 has been there from the beginning. I've deleted my initial comment.

dimxy commented 1 week ago

btw I managed to build marmara.exe (from fresh repo though) on ubuntu 18.04 and 20.04 (libcc.dll present in the src dir too)

DeckerSU commented 1 week ago

btw I managed to build marmara.exe (from fresh repo though) on ubuntu 18.04 and 20.04

Ubuntu 22.04.5 LTS, (fresh repo clone, developement branch)

Steps to reproduce:

  1. ./zcutil/build.sh -j8 - Ok.
  2. ./zcutil/build-win.sh -j8 - Fail with: 
    make: *** No rule to make target 'libcc.dll', needed by 'marmarad.exe'.  Stop.

    And in the logs after (6) we can see:

    
+ echo Making cclib...
Making cclib...
+ ./makecustom

Linux make: Nothing to be done for 'all'. CUSTOMCC BUILD SUCCESSFUL

p.s. Confirmed. The Windows build fails if ./src/cc/customcc.so exists. The following will work:

rm ./src/cc/customcc.so
./zcutil/build-win.sh -j8

However, the following will not:

touch ./src/cc/customcc.so
./zcutil/build-win.sh -j8

So, if customcc.so remains from previous builds, the Windows binaries will not be built successfully.

p.p.s. And actually, libcc.dll is not a PE32+ executable (DLL) (console) x86-64, for MS Windows. It's an Intel amd64 COFF object file, meaning it's a Linux binary. It’s linked with the resulting binary through this line: marmarad_LDADD += libcc.dll $(LIBSECP256K1). If you check the import sections of the resulting PE executable, you’ll see that it has no dependencies on libcc.dll, meaning it’s being statically linked anyway. 😉

rumeysayilmaz commented 1 week ago

p.p.s. One more note: It’s better to use your own DNS seeder rather than fixed seed nodes. This way, it will be easier to update A-records if the seed nodes change, rather than modifying hardcoded seed nodes.

@DeckerSU How can we do so? Could you explain how this approach can be implemented in the codebase?

Btw, we were unable to get a successful macOS build for marmara due to gcc. We would like to create another PR for this. We have noticed the following PRs in the komodo release.

How can we adopt these for marmara? We would appreciate your guidance.

dimxy commented 1 week ago

you’ll see that it has no dependencies on libcc.dll, meaning it’s being statically linked anyway.

It's built with -c flag. So it is named incorrectly but I guess still needed to build executable

DeckerSU commented 1 week ago

@DeckerSU How can we do so? Could you explain how this approach can be implemented in the codebase?

Adding a DNS seeder to the Marmara codebase is relatively easy to do. First, add your DNS seeder in sources here:

https://github.com/marmarachain/marmara/blob/69277d1d711c48f2ef2ca6cb55d3da59a6ce20a3/src/chainparams.cpp#L185

For example:

vSeeds.push_back(CDNSSeedData("Marmara Super DNS Seeder", "mcl.komodoseeds.com"));

Then, create A-records for mcl.komodoseeds.com that point to your seed nodes. For example, mcl.komodoseeds.com already contains the IPv4 addresses of the MCL seed nodes. Here's what you'll see if you check it:

dig mcl.komodoseeds.org @1.1.1.1

; <<>> DiG 9.16.50-Debian <<>> mcl.komodoseeds.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18827
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mcl.komodoseeds.org.       IN  A

;; ANSWER SECTION:
mcl.komodoseeds.org.    300 IN  A   5.189.149.242
mcl.komodoseeds.org.    300 IN  A   161.97.146.150
mcl.komodoseeds.org.    300 IN  A   149.202.158.145

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Sep 20 14:06:32 UTC 2024
;; MSG SIZE  rcvd: 96

Do the same for *.marmara.io by creating A-records that point to your seed nodes. Then, include these updated DNS seeders in the Marmara codebase.

DeckerSU commented 1 week ago

Btw, we were unable to get a successful macOS build for marmara due to gcc.

As you mentioned above, the Komodo codebase uses Clang as the native macOS compiler. Therefore, you can follow the same approach. To achieve this, cherry-pick the necessary commits from the Komodo pull request: https://github.com/KomodoPlatform/komodo/pull/618.

DeckerSU commented 1 week ago

It's built with -c flag. So it is named incorrectly but I guess still needed to build executable

Yes, of course, the custom CC library is necessary to build. However, there's no need to explicitly reference its .dll since it’s not a dynamically linked library. Instead, it's included as a static dependency in the binaries. We should build the static libcc.a library, as it’s done in the upstream Komodo codebase. The current method of building CCLib not only results in the errors mentioned but also causes confusion.