What flavor of underlying EVM is Substrate Frontier using (the EVM-compatible client)? - smartcontracts

I was able to successfully build my own Ethereum-compatible Substrate by basically following the Substrate Dev Frontier Workshop tutorial ( which uses SputnikVM as the underlying EVM engine, as per the Frontier Evm Documentation ).
I am aware of the fact that Ethereum is behaving more or less differently after each for, like for example, a decrease or increase of Gas costs of various EVM OPCODEs after some forks.
That being said, what kind of Ethereum is this Sputnik-based client exactly? Is this client similar to Berlin, Istanbul or similar to something older like Homestead or Byzantium? Should I use the latest solc compiler like 0.8.6+commit.11564f7e or should I use something older like 0.6.0+commit.26b70077 or 0.4.0+commit.acd334c9 ?
I would like to know because I need to document exactly what the gas cost of every contract deployment or method call or, prevent incompatibility.

The Sputnik evm implementation contains different flavors of EvmConfig for you to choose from.
If you look into the source code, you will find four of them:
impl Config {
/// Frontier hard fork configuration.
pub const fn frontier() -> Config { ... }
/// Istanbul hard fork configuration.
pub const fn istanbul() -> Config { ... }
/// Berlin hard fork configuration.
pub const fn berlin() -> Config { ... }
/// london hard fork configuration.
pub const fn london() -> Config { ... }
}
According to frontier's pallet-evm documentation
The gas configurations are configurable. Right now, a pre-defined London hard fork configuration option is provided.
Thus currently they are using the london hard fork configuration, which is confirmed by this commit, which shows they switched the default config from istanbul to london:
...
/// EVM config used in the module.
fn config() -> &'static EvmConfig {
- &ISTANBUL_CONFIG
+ &LONDON_CONFIG
}
}
## -571,7 +571,7 ## impl GasWeightMapping for () {
}
}
-static ISTANBUL_CONFIG: EvmConfig = EvmConfig::istanbul();
+static LONDON_CONFIG: EvmConfig = EvmConfig::london();
...
If you want detailed parameters of each hard fork, be sure to check here

Related

Neo4j 3.5's embeded database does not seem to persist data

I am trying to build a small command line tool that will store data in a neo4j graph. To do this I have started experimenting with Neo4j3.5's embedded databases. After putting together the following example I have found that either the nodes I am creating are not being saved to the database or the method of database creation is overwriting my previous run.
The Example:
fun main() {
//Spin up data base
val graphDBFactory = GraphDatabaseFactory()
val graphDB = graphDBFactory.newEmbeddedDatabase(File("src/main/resources/neo4j"))
registerShutdownHook(graphDB)
val tx = graphDB.beginTx()
graphDB.createNode(Label.label("firstNode"))
graphDB.createNode(Label.label("secondNode"))
val result = graphDB.execute("MATCH (a) RETURN COUNT(a)")
println(result.resultAsString())
tx.success()
}
private fun registerShutdownHook(graphDb: GraphDatabaseService) {
// Registers a shutdown hook for the Neo4j instance so that it
// shuts down nicely when the VM exits (even if you "Ctrl-C" the
// running application).
Runtime.getRuntime().addShutdownHook(object : Thread() {
override fun run() {
graphDb.shutdown()
}
})
}
I would expect that every time I run main the resulting query count will increase by 2.
That is currently not the case and I can find nothing in the docs that references a different method of opening an already created embedded database. Am I trying to use the embedded database incorrectly or am I missing something? Any help or info would be appreciated.
build Info:
Kotlin jvm 1.4.21
Neo4j-comunity-3.5.35
Transactions in neo4j 3.x have a 3 stage model
create
success / failure
close
you missed the third, which would then commit or rollback.
You can use Kotlin's use as Transaction is an AutoCloseable

How do you run the main binary and then run tests based on it in Rust?

I have written a webserver which requires some complicated setup and teardown, and am trying to write unit tests. Axum does provide examples using the Tower OneShot function, but these don't easily allow the full flow of the setup. How would I run the full server, and then run additional code to test it (using reqwest) with cargo test?
The CLI book has a nice approach shown:
# add this to your Cargo.toml
[dev-dependencies]
assert_cmd = "2.0"
predicates = "2.1"
Then you can write a test like this:
// tests/cli.rs
use assert_cmd::prelude::*; // Add methods on commands
use predicates::prelude::*; // Used for writing assertions
use std::process::Command; // Run programs
#[test]
fn file_doesnt_exist() -> Result<(), Box<dyn std::error::Error>> {
let mut cmd = Command::cargo_bin("your-binary-name")?;
cmd.arg("foobar").arg("test/file/doesnt/exist");
cmd.assert()
.failure()
.stderr(predicate::str::contains("could not read file"));
Ok(())
}
The main essence is this Command::cargo_bin("your-binary-name")?
That is documented in the assert_cmd crate
That allows you to call your binary from a test, without the need to compile it first, cargo takes care of it.
See the_real_deal in this example https://github.com/tokio-rs/axum/blob/main/examples/testing/src/main.rs

How to mimic Optaplanner 7's MoveIteratorFactoryToMoveSelectorBridge in Optaplanner 8

We have implemented a custom construction heuristic with Optaplanner 7. We didn't use a simple CustomPhaseCommand; Instead, we extend MoveSelectorConfig and override buildBaseMoveSelector to return our own MoveFactory wrapped in a MoveIteratorFactoryToMoveSelectorBridge. We decided to do so, because it gives us the following advantages:
global termination config is supported out of the box
type safe configuration from code (no raw Strings)
With Optaplanner 8 the method buildBaseMoveSelector is gone from the MoveSelectorConfig API and building a custom config class seems to be prevented in the new implementation of MoveSelectorFactory.
Is it still possible to inject a proper custom construction heuristic into the Optaplanner 8 configuration and if yes, how? Or should we be using a CustomPhaseCommand with a custom self-implemented termination?
EDIT:
For clarity, in Optaplanner 7 we had the following snippet in our Optaplanner-config (defined in kotlin code):
ConstructionHeuristicPhaseConfig().apply {
foragerConfig = ConstructionHeuristicForagerConfig().apply {
pickEarlyType = FIRST_FEASIBLE_SCORE
}
entityPlacerConfig = QueuedEntityPlacerConfig().apply {
moveSelectorConfigList = listOf(
CustomMoveSelectorConfig().apply {
someProperty = 1
otherProperty = 0
}
)
}
},
CustomMoveSelectorConfig extends MoveSelectorConfig and overrides buildBaseMoveSelector:
class CustomMoveSelectorConfig(
var someProperty: Int = 0,
var otherProperty: Int = 0,
) : MoveSelectorConfig<CustomMoveSelectorConfig>() {
override fun buildBaseMoveSelector(
configPolicy: HeuristicConfigPolicy?,
minimumCacheType: SelectionCacheType?,
randomSelection: Boolean,
): MoveSelector {
return MoveIteratorFactoryToMoveSelectorBridge(
CustomMoveFactory(someProperty, otherProperty),
randomSelection
)
}
To summarize: We really need to plug our own MoveSelector with the custom factory. I think this is not possible with Optaplanner 8 at the moment.
Interesting extension.
Motivation for the changes in 8:
the buildBaseMoveSelector was not public API (the config package was not in the api package, we only guaranteed XML backwards compatibility for package config in 7). Now, we also guarantee API backwards compatibility for package config, so including programmatic configuration, because we moved all build* methods out of it.
In 8.2 or later we want to internalize the configuration in the SolverFactory, so we can build thousands of Solver instances faster. For example, loading classes wouldn't to be done only at SolverFactory build, once, no longer at every Solver build.
Anyway, let's first see if you can use the default way to override the moves of the CH, by explicitly configuring the queuedEntityPlacer and it's MoveIteratorFactory? https://docs.optaplanner.org/latestFinal/optaplanner-docs/html_single/#allocateEntityFromQueueConfiguration
I guess not, because you'd need mimic support... for the selected entity you need to generate n moves, but always the same entity during 1 placement (hence the need for mimicing).
Clearly, the changes in 8 prevent users from plugging in their own MoveSelectors (= which is an internal API, but anyway). We might be able to add an internal API to allow that again.

How to use Gradle liquibaseRuntime configuration in a Kotlin/Multiplatform project

Currently, I'm porting my Spring Boot build.gradle.kts configuration to the Kotlin/MP stack. I don't know what to do with one part of the liquibaseRuntime configuration. The original config looks like:
// other dependencies omitted
liquibaseRuntime("org.liquibase:liquibase-core")
liquibaseRuntime("org.liquibase.ext:liquibase-hibernate5:3.8")
liquibaseRuntime(sourceSets.getByName("main").compileClasspath)
liquibaseRuntime(sourceSets.getByName("main").output)
liquibaseRuntime("org.postgresql:postgresql")
liquibaseRuntime("org.springframework.boot:spring-boot:$springBootVersion")
Some part of this config possibly can be replaced with:
sourceSets {
val jvmMain by getting {
dependencies {
configurations["liquibaseRuntime"].dependencies.addAll(listOf(
DefaultExternalModuleDependency("org.liquibase", "liquibase-core", null, "default"),
DefaultExternalModuleDependency("org.liquibase.ext", "liquibase-hibernate5", "3.8", "default"),
DefaultExternalModuleDependency("org.postgresql", "postgresql", null, "default"),
DefaultExternalModuleDependency("org.springframework.boot", "spring-boot", "2.2.4.RELEASE", "default")
// DefaultSelfResolvingDependency(configurations["compileClasspath"])
))
I've got stuck with these two and don't know what to do:
liquibaseRuntime(sourceSets.getByName("main").compileClasspath)
liquibaseRuntime(sourceSets.getByName("main").output)
They add instances of the dependency class DefaultSelfResolvingDependency (they also seem to be wrapped with some proxy). Looking through the liquibase-gradle plugin code didn't help.
So, how should I port these two dependencies?
Not familiar with with the Liquibase Gradle plugin. My assumption is you have applied the plugin in the following manner:
plugins {
id("org.liquibase.gradle") version "2.0.2"
}
Then you should be able to do what you have normally:
dependencies {
liquibaseRuntime("org.liquibase:liquibase-core")
liquibaseRuntime("org.liquibase.ext:liquibase-hibernate5:3.8")
liquibaseRuntime("org.postgresql:postgresql")
liquibaseRuntime("org.springframework.boot:spring-boot:$springBootVersion")
}
If for some reason that didn't work out-of-the-box, then you need to help Gradle's Kotlin DSL by explicitly retrieving a reference of the configuration:
val liquibaseRuntime by configurations
dependencies {
liquibaseRuntime("org.liquibase:liquibase-core")
liquibaseRuntime("org.liquibase.ext:liquibase-hibernate5:3.8")
liquibaseRuntime(sourceSets.getByName("main").compileClasspath)
liquibaseRuntime(sourceSets.getByName("main").output)
liquibaseRuntime("org.postgresql:postgresql")
liquibaseRuntime("org.springframework.boot:spring-boot:$springBootVersion")
}
You could also do the following as well:
dependencies {
"liquibaseRuntime"("org.liquibase:liquibase-core")
"liquibaseRuntime"("org.liquibase.ext:liquibase-hibernate5:3.8")
// ...
}
Reference: Understanding what to do when type-safe model accessors are not available
Now these two lines do not make sense to me.
liquibaseRuntime(sourceSets.getByName("main").compileClasspath)
liquibaseRuntime(sourceSets.getByName("main").output)
According to the API documentation for DependencyHandler, there are certain allowed notations. A sourceSet is not one of them. So not sure what to do there.

Running a main-like in a non-main package

We have a package with a fair number of complex tests. As part of the test suite, they run on builds etc.
func TestFunc(t *testing.T) {
//lots of setup stuff and defining success conditions
result := SystemModel.Run()
}
Now, for one of these tests, I want to introduce some kind of frontend which will make it possible for me to debug a few things. It's not really a test, but a debug tool. For this, I want to just run the same test but with a Builder pattern:
func TestFuncWithFrontend(t *testing.T) {
//lots of setup stuff and defining success conditions
result := SystemModel.Run().WithHTTPFrontend(":9999")
}
The test then would only start if I send a signal via HTTP from the frontend. Basically WithHTTPFrontend() just waits with a channel on a HTTP call from the frontend.
This of course would make the automated tests fail, because no such signal will be sent and execution will hang.
I can't just rename the package to main because the package has 15 files and they are used elsewhere in the system.
Likewise I haven't found a way to run a test only on demand while excluding it from the test suite, so that TestFuncWithFrontend would only run from the commandline - I don't care if with go run or go test or whatever.
I've also thought of ExampleTestFunc() but there's so much output produced by the test it's useless, and without defining Output: ..., the Example won't run.
Unfortunately, there's also a lot of initialization code at (private, i.e. lower case) package level that the test needs. So I can't just create a sub-package main, as a lot of that stuff wouldn't be accessible.
It seems I have three choices:
Export all this initialization variables and code with upper case, so that I could be using it from a sub-main package
Duplicate the whole code.
Move the test into a sub-package main and then have a func main() for the test with Frontend and a _test.go for the normal test, which would have to import a few things from the parent package.
I'd rather like to avoid the second option...And the first is better, but isn't great either IMHO. I think I'll go for the third, but...
am I missing some other option?
You can pass a custom command line argument to go test and start the debug port based on that. Something like this:
package hello_test
import (
"flag"
"log"
"testing"
)
var debugTest bool
func init() {
flag.BoolVar(&debugTest, "debug-test", false, "Setup debugging for tests")
}
func TestHelloWorld(t *testing.T) {
if debugTest {
log.Println("Starting debug port for test...")
// Start the server here
}
log.Println("Done")
}
Then if you want to run just that specific test, go test -debug-test -run '^TestHelloWorld$' ./.
Alternatively it's also possible to set a custom environment variable that you check in the test function to change behaviour.
I finally found an acceptable option. This answer
Skip some tests with go test
brought me to the right track.
Essentially using build tags which would not be present in normal builds but which I can provide when executing manually.